Re: svn commit: r196777 - head/sys/dev/ahci

[ Available lists | Index of svn-src-all | Month of Sep 2009 | Week of 3 Sep 2009 | Raw email | View thread | Wrap long lines | Reply | Tag ]
From
Scott Long <scottl@samsco.org>
Date
3 Sep 2009 16:17:53
Subject
Re: svn commit: r196777 - head/sys/dev/ahci
Message-ID
20090903101015.P20031@pooker.samsco.org


[ Hide this part ]
On Thu, 3 Sep 2009, Alexander Motin wrote:
> Scott Long wrote:
>> On Thu, 3 Sep 2009, Alexander Motin wrote:
>>> Scott Long wrote:
>>>> In this case, set maxio to 64k, not 127.5k. You'll typically get much
>>>> better i/o performance out of two 64k transfers
>>>> than you will out of one 127.k transfer and one 512 bytes transfer, which
>>>> is what the block layer will give you if
>>>> you try to send 128k.
>>>
>>> Couldn't it be somehow handled on that level?
>>
>> It's a limitation of the paticular hardware, not the OS. Plain disks will
>> behave like this, but RAID controllers might now. But if you want to add
>> this feature to the upper layers, be my guest.
>
> Huh. May be sometimes later.
>
>>> Limiting maxio from 127.5K to 64K is also a penalty for requests with
>>> length in that range.
>>
>> Most I/O that goes to a disk comes from one of the VM pagers, and is thus
>> page aligned and multi-of-page sized. Breaking one of these requests up
>> into sub-page sized requests costs a whole lot more than what you are
>> assuming. We analyzed exactly this situation a few years ago at Yahoo and
>> came to this conclusion.
>
> Sure, 127.5K is ugly, but what's about 96K or 112K? Is there benefits
> it strictly in power of 2?
It's convenient. We've analyzed the combinations. I'm just trying to
offer some advice from experience. I'm going to drop the conversation
now.

Scott



Elapsed time: 0.189 seconds