Re: [PATCH 87/88] Add configurable prefetch size for layoutget

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/10/2011 07:19 PM, Peng Tao wrote:
> On Sat, Jun 11, 2011 at 7:20 AM, Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote:
>> On 06/10/2011 12:23 PM, Benny Halevy wrote:
>>> On 2011-06-10 10:09, tao.peng@xxxxxxx wrote:
>>>
>>> A simple algorithm I can suggest is:
>>> - on initialization, calculate and save, per layout driver
>>>   - maximum layout size
>>>     - take into account csr_fore_chan_attrs.ca_maxresponsesize and possible other parameters
>>>   - keep a working copy of the maximum value and the calculated copy.
>>>   - alignment value.
>>> - on miss, see if there's an adjacent layout segment in cache
>>> - if found, ask for twice the found segment size, up to the maximum value,
>>>   aligned on the alignment value.
>>> - if the server returns less the layoutget range, keep note of the returned length
>>>   (but not adjust maximum yet, as the server may return a short segment for various
>>>    reasons)
>>> - if the server is consistent about returning less than was asked, adjust the
>>>   - working copy of the maximum length
>>> - if the maximum was adjusted try bumping it up after X (TBD) layoutgets or T seconds
>>>   to see if that was just due to high load or conflicts on the server
>>> - on any error returned for LAYOUTGET reset the algorithm parameters
>>> - on session reestablishment recalculate maximums.
>>>
>>> Benny
>>>
>>
>> I completely disagree with all this. NACK!
>>
>> The only proper thing a client can do is ask for what it needs, and only the application
>> can do that, because at the VFS level it is only second guessing, and is completely
>> pointless.
>>
>> The only one that can know about structure, alignments, optimal IO sizes and layouts
>> is the server. The server even have more information to second guess the application
>> from the file size information and it's share and lock disposition. Please see my
>> simple Server side algorithm.
> Well, IMO, client is closer to applications and should have a better
> position at "guessing" application's workload.
> 
> A simple example, when a client asks for a layout, server would have
> no idea if client is doing layout prefetch, or if it really need that
> range to complete its work. But the client knows it for sure.
> 

What is layout prefetch? we don't do any in the Linux client.

And your example does not make any sense. If a theoretical stupid client does
"layout prefetch" what ever that means, how is it related to the application?

There is not a single information a client has the the server does not. Look at
your patch. Set an arbitrary value at client setup. That same arbitrary value
can be setup at server. Look at benny's algorithm. It can be done just the same
at the server side. (Which does not mean it is a good algorithm)

Just take that patch of yours, but instead of at client side. Put it at server
side. You will achieve exact same results. Only you configure one server instead
of every client.

And no way in hell I let that go into the Linux generic client!

Boaz

>>
>> Because you must understand one most important thing. Any smart decision a client can
>> make will be after it received the layout (stripe_unit, number-of-devices etc..) But
>> at that time it is too late it already sent the layout_get. Only the server knows
>> before hand what is the most optimal size. The client should just be a transparent
>> pipe from application to the server. It should never ever set policy. Only a Server
>> can/should do that.
>>
>> Lets put the efforts and algorithms where they belong, please?
>>
>> Boaz
>>
> 
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux