[lkml]   [2003]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [BENCHMARK] 2.5.63-mm2 + i/o schedulers with contest
Con Kolivas wrote:

>On Tue, 4 Mar 2003 03:18 pm, Nick Piggin wrote:
>>small randomish reads vs large writes _is_ where AS really can
>>perform better than non a non AS scheduler. Unfortunately gcc
>>doesn't have the _best_ IO pattern for AS ;)
>Yes I recall this discussion against a gcc based benchmark. However it is
>interesting that it still performed by far the best.
Yes, AS obviously does help gcc against io_load. My
"unfortunately" comment was just a pun, of course we
don't want to just test where AS does well.

>>>CFQ and DL scheduler were faster compiling the kernel under read_load,
>>>list_load and dbench_load.
>>>Mem_load result of AS being slower was just plain weird with the result
>>>rising from 100 to 150 during testing.
>>I would like to see if AS helps much with a swap/memory
>>thrashing load.
>That's what mem_load is. It repeatedly tries to access 110% of available ram.
>quote from original post:
>Kernel [runs] Time CPU% Loads LCPU% Ratio
>2.5.63 3 104 75.0 57.7 1.9 1.32
>2.5.63-mm2cfq 3 101 76.2 52.3 2.0 1.28
>2.5.63-mm2 3 132 59.1 90.3 2.3 1.65
>2.5.63-mm2dl 3 100 79.0 52.0 2.0 1.27
>Note that mm2 with AS performed equivalent to the other schedulers but on
>later runs took longer. (99, 148,150) This is usually suspicious of a memory
>leak that contest is unusually sensitive at picking up, but there wasn't
>anything suspicious about the meminfo after these runs, and none of the other
>loads changed over time. io_load usually shows drastic prolongation when
>memory is leaking.
Ah ok. And this change didn't affect other schedulers on mm2? Is
it reproducable with AS? I'll have to keep this in mind and take
another look at it after a few othe bugs are fixed.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:33    [W:0.038 / U:0.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site