昨日ばったり会った編集者さんに、「エロはダメ！せめて萌えにしてください！」と力説される。
そんなつもりじゃなかったんだよー


しかし、萌えはOKなのか。新しい発見をしてしまった。

今月のブックマークでやたら面白いのがあったので晒してみる

IGA-OS 純技術的に面白い読み物

これは裏返していうと非技術的な要素がイマイチという事です。
やはり期待されているのはエロか！エロなのか！？

Kernel Watchに期待するものも人それぞれなんだなー。と思いました。
来月に反映できるかどうかは分かりませんが、今後とも精進したいと思います。

と怒られた。ふが

本来は ^---$ （正確に - を３つだけ含む行）だけが、特殊な意味を持つんだけれども、
多くの人が buggy own scriptを使っていて、罫線っぽく

-------------------

とか書くと混乱してしまうのだそうだ。
そんなん気づくか！

出ました

公開されました。
今回はＳＳＤの事しか書いてない。ああダメ人間だなぁ・・

http://www.atmarkit.co.jp/flinux/rensai/watch2009/watch08a.html














ところで督促厳しかった割には原稿渡してから公開までの期間は普段とあまり変わらなかったような。つまり、締め切りを守るとは最初から思われていないので大きくバッファが取ってあるんだと思うんです。
（ポン！）そうか、じゃあもっと遅れても大丈夫なんだ。

な、なんだってーーー

（この話はフィクションです）

LWNの記事(http://lwn.net/Articles/351298/)経由で知ったのだがRHELのサポート期間が７年というのに不満の声があるようだ。

元発言Blog：　http://dag.wieers.com/blog/is-7-years-of-rhel-support-still-sufficient

要約すると
・現在のRHEL5は2014年3月までしかサポートされない
・ハードウェアの切り替えサイクルは平均で４年（米国での話の気がするな）
・2010年時点でRHEL6はまだ出荷されていない(or 管理者が評価中で実運用に投入できない）
と、考えると、2010年はRHEL環境でビジネスがしにくい。RHEL5のEOL(End of Life)がハードウェアの切り替えより先に来てしまう。

という感じらしい。たしかに問題だなー
やっぱ１０年ぐらい欲しいよね。サポート期間。欲しいというより現状のメジャーリリース間隔の実情（約３年）から逆算すると必要。

つまり、昔はLinuxに足りないfeatureが多かったので頻繁なメジャーアップが歓迎された。だから７年でもEOLにならなかった。でも、Linuxが成熟するにつれてメジャーリリース間隔が延びていっているので、７年では全然話にならないケースが出てきている。と

興味深い

Ingo がBFSとCFSとベンチマーク比較して、BFS全然速くないよ。と主張している

Ingo のメール

hi Con,



I've read your BFS announcement/FAQ with great interest:



    http://ck.kolivas.org/patches/bfs/bfs-faq.txt



First and foremost, let me say that i'm happy that you are hacking 

the Linux scheduler again. It's perhaps proof that hacking the 

scheduler is one of the most addictive things on the planet ;-)



I understand that BFS is still early code and that you are not 

targeting BFS for mainline inclusion - but BFS is an interesting 

and bold new approach, cutting a _lot_ of code out of 

kernel/sched*.c, so it raised my curiosity and interest :-)



In the announcement and on your webpage you have compared BFS to 

the mainline scheduler in various workloads - showing various 

improvements over it. I have tried and tested BFS and ran a set of 

benchmarks - this mail contains the results and my (quick) 

findings.



So ... to get to the numbers - i've tested both BFS and the tip of 

the latest upstream scheduler tree on a testbox of mine. I 

intentionally didnt test BFS on any really large box - because you 

described its upper limit like this in the announcement:



-----------------------

|

| How scalable is it?

|

| I don't own the sort of hardware that is likely to suffer from 

| using it, so I can't find the upper limit. Based on first 

| principles about the overhead of locking, and the way lookups 

| occur, I'd guess that a machine with more than 16 CPUS would 

| start to have less performance. BIG NUMA machines will probably 

| suck a lot with this because it pays no deference to locality of 

| the NUMA nodes when deciding what cpu to use. It just keeps them 

| all busy. The so-called "light NUMA" that constitutes commodity 

| hardware these days seems to really like BFS.

|

-----------------------



I generally agree with you that "light NUMA" is what a Linux 

scheduler needs to concentrate on (at most) in terms of 

scalability. Big NUMA, 4096 CPUs is not very common and we tune the 

Linux scheduler for desktop and small-server workloads mostly.



So the testbox i picked fits into the upper portion of what i 

consider a sane range of systems to tune for - and should still fit 

into BFS's design bracket as well according to your description: 

it's a dual quad core system with hyperthreading. It has twice as 

many cores as the quad you tested on but it's not excessive and 

certainly does not have 4096 CPUs ;-)



Here are the benchmark results:



  kernel build performance:

     http://redhat.com/~mingo/misc/bfs-vs-tip-kbuild.jpg     



  pipe performance:

     http://redhat.com/~mingo/misc/bfs-vs-tip-pipe.jpg



  messaging performance (hackbench):

     http://redhat.com/~mingo/misc/bfs-vs-tip-messaging.jpg  



  OLTP performance (postgresql + sysbench)

     http://redhat.com/~mingo/misc/bfs-vs-tip-oltp.jpg



Alas, as it can be seen in the graphs, i can not see any BFS 

performance improvements, on this box.



Here's a more detailed description of the results:



| Kernel build performance

---------------------------



  http://redhat.com/~mingo/misc/bfs-vs-tip-kbuild.jpg     



In the kbuild test BFS is showing significant weaknesses up to 16 

CPUs. On 8 CPUs utilized (half load) it's 27.6% slower. All results 

(-j1, -j2... -j15 are slower. The peak at 100% utilization at -j16 

is slightly stronger under BFS, by 1.5%. The 'absolute best' result 

is sched-devel at -j64 with 46.65 seconds - the best BFS result is 

47.38 seconds (at -j64) - 1.5% better.



| Pipe performance

-------------------



  http://redhat.com/~mingo/misc/bfs-vs-tip-pipe.jpg



Pipe performance is a very simple test, two tasks message to each 

other via pipes. I measured 1 million such messages:



   http://redhat.com/~mingo/cfs-scheduler/tools/pipe-test-1m.c



The pipe test ran a number of them in parallel:



   for ((i=0;i<$NR;i++)); do ~/sched-tests/pipe-test-1m & done; wait



and measured elapsed time. This tests two things: basic scheduler 

performance and also scheduler fairness. (if one of these parallel 

jobs is delayed unfairly then the test will finish later.)



[ see further below for a simpler pipe latency benchmark as well. ]



As can be seen in the graph BFS performed very poorly in this test: 

at 8 pairs of tasks it had a runtime of 45.42 seconds - while 

sched-devel finished them in 3.8 seconds.



I saw really bad interactivity in the BFS test here - the system 

was starved for as long as the test ran. I stopped the tests at 8 

loops - the system was unusable and i was getting IO timeouts due 

to the scheduling lag:



 sd 0:0:0:0: [sda] Unhandled error code

 sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT

 end_request: I/O error, dev sda, sector 81949243

 Aborting journal on device sda2.

 ext3_abort called.

 EXT3-fs error (device sda2): ext3_journal_start_sb: Detected aborted journal

 Remounting filesystem read-only



I measured interactivity during this test:



   $ time ssh aldebaran /bin/true

   real  2m17.968s

   user  0m0.009s

   sys   0m0.003s



A single command took more than 2 minutes.



| Messaging performance

------------------------



  http://redhat.com/~mingo/misc/bfs-vs-tip-messaging.jpg  



Hackbench ran better - but mainline sched-devel is significantly 

faster for smaller and larger loads as well. With 20 groups 

mainline ran 61.5% faster.



| OLTP performance

--------------------



http://redhat.com/~mingo/misc/bfs-vs-tip-oltp.jpg



As can be seen in the graph for sysbench OLTP performance 

sched-devel outperforms BFS on each of the main stages:



   single client load   (   1 client  -   6.3% faster )

   half load            (   8 clients -  57.6% faster )

   peak performance     (  16 clients - 117.6% faster )

   overload             ( 512 clients - 288.3% faster )



| Other tests

--------------



I also tested a couple of other things, such as lat_tcp:



  BFS:          TCP latency using localhost: 16.5608 microseconds

  sched-devel:  TCP latency using localhost: 13.5528 microseconds [22.1% faster]



lat_pipe:



  BFS:          Pipe latency: 4.9703 microseconds

  sched-devel:  Pipe latency: 2.6137 microseconds [90.1% faster]



General interactivity of BFS seemed good to me - except for the 

pipe test when there was significant lag over a minute. I think 

it's some starvation bug, not an inherent design property of BFS, 

so i'm looking forward to re-test it with the fix.



Test environment: i used latest BFS (205 and then i re-ran under 

208 and the numbers are all from 208), and the latest mainline 

scheduler development tree from:



  http://people.redhat.com/mingo/tip.git/README



Commit 840a065 in particular. It's on a .31-rc8 base while BFS is 

on a .30 base - will be able to test BFS on a .31 base as well once 

you release it. (but it doesnt matter much to the results - there 

werent any heavy core kernel changes impacting these workloads.)



The system had enough RAM to have the workloads cached, and i 

repeated all tests to make sure it's all representative. 

Nevertheless i'd like to encourage others to repeat these (or 

other) tests - the more testing the better.



I also tried to configure the kernel in a BFS friendly way, i used 

HZ=1000 as recommended, turned off all debug options, etc. The 

kernel config i used can be found here:



  http://redhat.com/~mingo/misc/config



( Let me know if you need any more info about any of the tests i

  conducted. )



Also, i'd like to outline that i agree with the general goals 

described by you in the BFS announcement - small desktop systems 

matter more than large systems. We find it critically important 

that the mainline Linux scheduler performs well on those systems 

too - and if you (or anyone else) can reproduce suboptimal behavior 

please let the scheduler folks know so that we can fix/improve it.



I hope to be able to work with you on this, please dont hesitate 

sending patches if you wish - and we'll also be following BFS for 

good ideas and code to adopt to mainline.



Thanks,



	Ingo

--

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

the body of a message to majordomo@vger.kernel.org

More majordomo info at  http://vger.kernel.org/majordomo-info.html

Please read the FAQ at  http://www.tux.org/lkml/

それに対する Con の返信。感じ悪いな

2009/9/7 Ingo Molnar :

> hi Con,



Sigh..



Well hello there.



>

> I've read your BFS announcement/FAQ with great interest:

>

>     http://ck.kolivas.org/patches/bfs/bfs-faq.txt



> I understand that BFS is still early code and that you are not

> targeting BFS for mainline inclusion - but BFS is an interesting

> and bold new approach, cutting a _lot_ of code out of

> kernel/sched*.c, so it raised my curiosity and interest :-)



Hard to keep a project under wraps and get an audience at the same

time, it is. I do realise it was inevitable LKML would invade my

personal space no matter how much I didn't want it to, but it would be

rude of me to not respond.



> In the announcement and on your webpage you have compared BFS to

> the mainline scheduler in various workloads - showing various

> improvements over it. I have tried and tested BFS and ran a set of

> benchmarks - this mail contains the results and my (quick)

> findings.



/me sees Ingo run off to find the right combination of hardware and

benchmark to prove his point.



[snip lots of bullshit meaningless benchmarks showing how great cfs is

and/or how bad bfs is, along with telling people they should use these

artificial benchmarks to determine how good it is, demonstrating yet

again why benchmarks fail the desktop]



I'm not interested in a long protracted discussion about this since

I'm too busy to live linux the way full time developers do, so I'll

keep it short, and perhaps you'll understand my intent better if the

FAQ wasn't clear enough.





Do you know what a normal desktop PC looks like? No, a more realistic

question based on what you chose to benchmark to prove your point

would be: Do you know what normal people actually do on them?





Feel free to treat the question as rhetorical.



Regards,

-ck



/me checks on his distributed computing client's progress, fires up

his next H264 encode, changes music tracks and prepares to have his

arse whooped on quakelive.

--

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

the body of a message to majordomo@vger.kernel.org

More majordomo info at  http://vger.kernel.org/majordomo-info.html

Please read the FAQ at  http://www.tux.org/lkml/

http://linux.slashdot.org/story/09/09/06/0433209/Con-Kolivas-Returns-With-a-Desktop-Oriented-Linux-Scheduler?from=rss

スラド本家で、Con Kolivasがまた新しいスケジューラ書いたよ。って取り上げてる。まあ、メインライン化はされないと思うけど、いつも同じメンツだと飽きるので新しい人がコードを引っさげて乱入してくるのは大歓迎