On Sun, Jun 12, 2011 at 10:40 PM, Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote: > 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? The example is just showing you that sometimes server does not know everything. And the thing it does not know, can have some impact on application IO performance. If client is asking for more than it needs and server is returning more than client asks for, application performance is impacted for sure. > > 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) True. And both client and server should have that some kind of algorithms implemented. Server can be smart. But it does not prevent client from being smart too. There can always be naive clients and naive servers. We can't prevent users from using them. And when users are dealing with naive servers, we can do better with the algorithm at client side, other than simply telling them "it's your fault not using the smart servers!". > > 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! While taking your side so firmly, would you mind telling why such kind of algorithm cannot be implemented at client side? > > 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 >>> >> >> >> > > -- Thanks, -Bergwolf -- 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
