05/12/07 20:11:50 yM4/VoR2
まぁ今更なんですが、一応。
URLﾘﾝｸ(debian.fam.cx)
264:login:Penguin
05/12/25 19:25:33 OkFXu416
gcc 3.4のAthlonXPでFirefoxを最適化してる
CFLAGS="-O2 -march=athlon-xp -mfpmath=sse -falign-functions=64 -falign-labels=6 -falign-jumps=6 -falign-loops=6 \
-DNDEBUG -DNO_DEBUG -DG_DISABLE_ASSERT -fomit-frame-pointer -ftracer -ffast-math -fno-unsafe-math-optimizations \
-fno-strict-aliasing -pipe -fpeel-loops -fbranch-target-load-optimize -fbranch-target-load-optimize2 \
-frename-registers -funroll-loops -freduce-all-givs -freorder-blocks -fno-reorder-functions"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden -fno-enforce-eh-specs"
-O -march=i586と大して体感速度変わらなくても気にしない
265:login:Penguin
06/01/12 23:52:05 lMwJjwVt
age
266:login:Penguin
06/01/21 07:01:19 vwfA/GBb
kernelに
I-pipe・Adaptive readahead
ckからvm-mappedパッチ、hzの値を任意に変更できるパッチを当てる
hzの数値は1728
後はsysctl.confに
kernel.threads-max = 65535
fs.file-max = 65535
vm.readahead_ratio = 100
vm.readahead_hit_rate = 5
vm.hardmaplimit = 0
vm.mapped = 10
追記
後はswapをパーティションからファイルに変更
ごわごわした体感がきびきびになった感じ
267:login:Penguin
06/02/16 19:39:29 I+0mKfgz
暇なのでflag晒してみる
-O2 -pipe -s -march=athlon64 -m32 -mfpmath=sse -msse -msse2 \
-funit-at-a-time -fomit-frame-pointer -momit-leaf-frame-pointer -fno-var-tracking \
-ftree-vectorize -ftracer -floop-optimize2 -funswitch-loops -ftree-loop-im \
-fgcse-sm -fgcse-las -fgcse-after-reload -fweb -frename-registers \
-funsafe-loop-optimizations -ffast-math
268:login:Penguin
06/02/18 12:38:45 GDUX4TR2
デバッグしないのならリンカーに-Wl,-s渡せば-Osにしなくとも充分サイズ縮まって速度は変わらないまま行けるな
姫野ベンチ
gcc -O2 -march=athlon-xp -pipe -Wl,-s size:8.3kb Grid-size=S 67MFLOPS
gcc -Os -march=athlon-xp -pipe -Wl,-s size:7.4kb Grid-size=S 57MFLOPS
-Wl,-s無しだと双方とも10kbオーバー。ベンチ結果は変わらず。
GCCは4.0.2
269:login:Penguin
06/02/18 12:51:00 M+2Pe4iM
x86な人は-mno-align-stringopsも悪くない
270:login:Penguin
06/02/23 14:09:30 ORgvzJHl
URLﾘﾝｸ(kernel.jakem.net)
から遺伝的アルゴリズムの部分を削除してみた、これはこれで音飛びしないし悪くないかも。x86の2.6.15でしかテストしてない。自己責任。
Index: 2.6/include/linux/sched.h
===================================================================
--- 2.6.org/include/linux/sched.h2005-08-15 16:16:26.000000000 -0500
+++ 2.6/include/linux/sched.h2005-08-15 16:18:21.000000000 -0500
@@ -143,6 +143,20 @@
#include <linux/spinlock.h>
/*
+ * These are the 'tuning knobs' of the scheduler:
+ *
+ * Default configurable timeslice is 100 msecs, maximum configurable
+ * timeslice is 1000 msecs and minumum configurable timeslice is 1 jiffy.
+ * Timeslices get renewed on task creation, on wake up and after they expire.
+ */
+#define MIN_TIMESLICE1
+#define DEF_TIMESLICE(10 * HZ / 1000)
+#define MAX_TIMESLICE(1000 * HZ / 1000)
+#define DEF_DESKTOP_TIMESLICE ((DEF_TIMESLICE > 10) ? (DEF_TIMESLICE / 10) : 1)
+
+#define DEFAULT_UNPRIV_RT_THRESHOLD 10
+
+/*
* This serializes "schedule()" and also protects
* the run-queue from deletions/modifications (but
* _adding_ to the beginning of the run-queue has
271:login:Penguin
06/02/23 14:10:30 ORgvzJHl
Index: 2.6/kernel/sched.c
===================================================================
--- 2.6.orig/kernel/sched.c2005-08-15 16:16:26.000000000 -0500
+++ 2.6/kernel/sched.c2005-08-15 16:18:21.000000000 -0500
@@ -85,3 +85,4 @@
-#define MIN_TIMESLICEmax(5 * HZ / 1000, 1)
-#define DEF_TIMESLICE(100 * HZ / 1000)
+#define MIN_TIMESLICE1
+#define DEF_TIMESLICE(10 * HZ / 1000)
+#define MAX_TIMESLICE(1000 * HZ / 1000)
#define ON_RUNQUEUE_WEIGHT 30
272:login:Penguin
06/02/26 14:26:39 P0wgzWH7
なんでHZは100、1000と来て半端な250なんだろう
500のほうがパフォーマンス・省電力的にもいいと思うんだが
273:login:Penguin
06/02/26 22:00:56 nHV3UYSp
>>272
ベンチとパッチを添えてLKMLへgo!
274:login:Penguin
06/02/27 11:02:02 1Egv0MIp
>>272
それLKMLで散々議論されたよ。
最終的には、リーナスの鶴の一声で終わった希ガス。
＃ぶっちゃけ、正しい値なんて無いよ(環境違うと値も変わるし)
275:login:Penguin
06/02/27 14:39:32 1LjKfRfr
gcc 4.1で姫野ベンチS
-O0 -pipe -DSMALL 83MFLOPS
-O1 -pipe -DSMALL 291MFLOPS
-O2 -pipe -DSMALL 258MFLOPS
-O3 -pipe -DSMALL 259MFLOPS
-O1が最速な件について
276:login:Penguin
06/02/27 18:25:56 1LjKfRfr
CPUはAthlonXP、
-O1に -fstrength-reduce -fprefetch-loop-arrays付けたら1割程ベンチ結果が良くなった
-O2や-O3の立場ないな、gcc4.1
277:login:Penguin
06/02/27 20:02:03 1Egv0MIp
>>275,276
詳細に知りたいなら
やはり生成されたコードみるのが一番だ。w
278:login:Penguin
06/02/27 23:18:51 74EhIevN
>>275
ヒント。footprint
279:login:Penguin
06/09/16 02:47:16 nWBaFZS+
保守
280:login:Penguin
07/05/11 10:24:21 IclmDtdK
>279
「定期的な保守が最良のパフォーマンスチューニング」という意味？
281:login:Penguin
07/05/14 17:51:36 /Taxc8HZ
>>252
たしかにそれも一理ある
282:login:Penguin
07/05/14 19:06:20 5fWNtpNo
うまく動いているものは触らない
283:login:Penguin
07/05/14 22:46:30 QX1St6KG
たかが「PC」サーバーなのに、テスト環境持ってない奴多すぎ。
テストして確信があって変更加える奴は、「うまく動いているものは触らない」
なんて言わないぜ。
>>280
あんたは正しい。
284:login:Penguin
07/05/26 00:42:48 0vvpPe8X
hosyu
285:login:Penguin
07/07/10 14:32:16 18GSmHEg
一日にわたって、どんなプロセスがいつ起動されてどの程度メモリと
CPU時間を消費し、どのていどディスクIOを発生させ、
また、最大でいくつTCPコネクションを同時に開いたかという
情報を収集したいと思っています。
（いままではトラブルっぽいときに top で眺めてアドホックに対処してました）
sysprof がその用途にかなっていると思うのですが、どうでしょうか？
また遠隔で ssh でログインするしかないのですが、その場合は
X をトンネルで飛ばすしかありませんか？
286:login:Penguin
07/07/11 00:00:27 KKfnKy5V
>>285
さあぁねえ
287:login:Penguin
07/07/11 01:19:56 QpW+YHM2
うまく動いている物は触る必要がないんじゃないのか？
必要なパフォーマンスが出ないとか機能が足りないとかセキュリティに
問題があるとか、なんかしらの必要が無いのに触りたいってのは、それ
こそテスト環境だけでやってろって話だと思うが。
と言ってみるてすｔ
288:login:Penguin
07/07/11 09:58:10 BD6VBK6/
mrtg
289:login:Penguin
07/07/13 20:45:38 2ZKs87kv
Tweak ubuntu for speed
URLﾘﾝｸ(tvease.net)
290:login:Penguin
07/08/05 02:09:21 YQ3bjemY
age
291:login:Penguin
07/08/08 02:22:53 G1QcNwNo
パフォーマンスチューニング考えるより
Quad-Coreを２ソケにした方が早いのには萎えた。
292:login:Penguin
07/08/08 02:27:44 gwGHMtux
そら当然じゃ…
293:login:Penguin
07/08/08 02:35:45 G1QcNwNo
ペンギン8匹出すためだけに
古いknoppixを入れてしまったw
294:login:Penguin
07/10/14 08:26:06 Z1+eNroa
URLﾘﾝｸ(opentechpress.jp)
でやってるDMA有効化って、最近のディストリは標準で有効になってますよね？
295:login:Penguin
07/10/14 20:20:14 iQTMbnsw
DMAは有効になってるものが多いけど、
multicountやreadaheadまで自動で最適化されているものは見たことがない
296:login:Penguin
07/10/30 14:55:24 Ur3y58dD
>>291
それをさらにチューニングするんだ
297:login:Penguin
07/11/24 00:44:56 lC7phVQh
blockdev --setraとかはどう？
298:login:Penguin
07/11/24 21:16:44 ydsrJmgw
どうもこうも…
299:login:Penguin
07/12/26 21:05:18 +vtor5nX
glibとかには-fpicつけて握るべき？
ロード減ったりする？
300:login:Penguin
08/03/26 15:09:40 cxp4sqCR
URLﾘﾝｸ(pastebin.windy.cx)
このように init が CPU 時間を 100% 食ってしまうことがあるのですが、
何が理由でこのようなことがおきるのでしょうか？
リブートすれば元に戻るのですが、何がきっかけで
このような状態になるのかわからず悩んでいます。
ディストリビューションによらず一年に一度くらい経験するので、
なにかカーネルオプションとかが影響しているのかとも思うのですが、
原因がわからないのでそのままにしています。どなたか
情報お持ちではないでしょうか？
301:login:Penguin
08/03/30 11:24:06 jFm+8ci3
>>300
niが50%くらいだから、SMPならなにかのデッドロックだと思う。
ユニなら判らん。
302:login:Penguin
08/05/05 18:09:53 GqcTgusP
>>300
HDD熱暴走は？
303:login:Penguin
08/07/20 12:17:54 CjO8L7rN
保守
304:login:Penguin
08/07/20 13:21:27 hIdKokXB
捕手
305:login:Penguin
08/07/20 13:46:53 QLBAJ0IH
投手
306:login:Penguin
08/07/20 15:33:49 DclP9fHP
野手
307:login:Penguin
08/07/20 18:17:54 8ABXsSuq
＼
::::: ＼
＼::::: ＼
＼::::: ＿ヽ ＿_ ＿
ヽ／, ／＿ ヽ/、 ヽ＿
// ／< ＿＿） l -,|__) >
|| ｜ < ＿＿）_ゝJ_)＿>
＼ ||.｜ < ＿__）_(＿)_ > シュシュ
＼| | <_＿__ノ_(＿)＿ )
ヾヽニニ/ー--'/
|_|＿t＿|_♀__|
９ ∂
６ ∂
(9_∂
308:login:Penguin
08/07/20 18:42:52 YovRPAEh
ジャンジャン
しゃいならー！
309:login:Penguin
08/10/02 22:47:42 VgcPNTwj
それなりのスペックのマシンでインテルのSSD試した奴いないのか？
リナではディスクアクセスの速度が起動速度に直結してるからめっさ早くなると思うけど