lkml.org 
[lkml]   [2009]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: CCISS performance drop in buffered disk reads in newer kernels
Miller, Mike (OS Dev) wrote:
> Ozan,
> I'm aware of the performance drop. Please see: http://bugzilla.kernel.org/show_bug.cgi?id=13127. I removed the huge read ahead value of 1024 that we used because users were complaining about small writes being starved. That was back around the 2.6.25 timeframe. Since that timeframe there have no changes in the main i/o path. I'll get back on this as time allows.
>
> Meanwhile, you can tweak some of the block layer tunables as such.
>
> echo 64 > /sys/block/cciss\!c0d1/queue/read_ahead_kb
> OR
> blockdev --setra 128 /dev/cciss/c0d1
>
> These are just example values. There is also max_hw_sectors_kb and max_sectors_kb that be adjusted.
>

Hi,

Actually the "#define READ_AHEAD 1024" was removed on March 2008 which
was included in the 2.6.25.y tree so 2.6.25.20 has 128kB read_ahead
value too.

*But* setting read_ahead to 2048 increases buffered disk read average
from 60~MB/s to 190~MB/s hence the kernel compile time drops to 2 minutes.

So maybe the regression/change is in another place?

The server is just a compile-farm so it's triggered by hand, compiles
distribution's packages and stays idle until the next compilation queue.
Is it safe/OK to use that 2048kB read_ahead value for such workload?

(max_hw_sectors_kb is 512 on my 2.6.25.20 setup and 1024 on 2.6.30.9 but
it seems that it's read-only)

Thanks!


\
 
 \ /
  Last update: 2009-12-07 19:25    [W:0.042 / U:0.344 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site