Re: Raw devices broken in 2.6.1? AND- 2.6.1 I/O degraded?

[Nick Piggin <piggin@cyberone.com.au>]

Andrew Morton wrote:

>"Curt" <curt@northarc.com> wrote:
>
>> >    Or you can put 2.6 on par by setting
>> >    /proc/sys/vm/dirty_background_ratio to 40 and dirty_ratio to 60.
>>
>> Okay will do, is there a good comprehensive resource where I can read up on
>> these (and presumably many other I/O related) variables?
>>
>
>We've been relatively good about keeping the in-kernel documentation up to
>date.  For this stuff, see Documentation/filesystems/proc.txt and
>Documentation/sysctl/vm.txt.
>
>
>> > Longer-term, if your customers are using scsi, you should ensure that the
>> > disks do not use a tag queue depth of more than 4 or 8.  More than that
>> and
>> > the anticipatory scheduler becomes ineffective and you won't get that
>> > multithreaded-read goodness.
>>
>> I've heard-tell of tweaking the elevator paramter to 'deadline', again could
>> you point me to a resource where I can read up on this? And forgive the
>> newbie-question, but is this a boot-time parameter, or a bit I can set in
>> the /proc system, or both?
>>
>
>It's boot-time only.  We were working on making it per-disk but that was
>quite complex and we really didn't get there in time.
>
>So add `elevator=deadline' to your kernel boot command line.  From my
>(brief) testing, it was a significant lose.  It needs more work though:
>2.6+deadline shouldn't be slower than 2.4.x
>
>

Another thing you can do which is runtime per-disk is set
/sys/block/???/queue/iosched/antic_expire to 0 which gives you
something quite like deadline.

>> > Please stay in touch, btw.  If we cannot get applications such as yours
>> > working well, we've wasted our time...
>>
>> I'll do what I can to provide real-world feedback, I want this to work too.
>>
>
>Thanks.
>

I'd be interested in taking a look at the io scheduler if you have
problems with these workloads in future.