On Sat, Jun 11, 2011 at 3:23 AM, Benny Halevy <benny@xxxxxxxxxx> wrote: > On 2011-06-10 10:09, tao.peng@xxxxxxx wrote: >> Hi, Benny, >> >> -----Original Message----- >> From: Benny Halevy [mailto:benny@xxxxxxxxxx] >> Sent: Friday, June 10, 2011 8:33 PM >> To: Peng, Tao >> Cc: bergwolf@xxxxxxxxx; rees@xxxxxxxxx; linux-nfs@xxxxxxxxxxxxxxx; honey@xxxxxxxxxxxxxx >> Subject: Re: [PATCH 87/88] Add configurable prefetch size for layoutget >> >> On 2011-06-10 02:00, tao.peng@xxxxxxx wrote: >>> Hi, Benny, >>> >>> Cheers, >>> -Bergwolf >>> >>> >>> -----Original Message----- >>> From: linux-nfs-owner@xxxxxxxxxxxxxxx [mailto:linux-nfs-owner@xxxxxxxxxxxxxxx] On Behalf Of Benny Halevy >>> Sent: Friday, June 10, 2011 5:23 AM >>> To: Peng Tao >>> Cc: Jim Rees; linux-nfs@xxxxxxxxxxxxxxx; peter honeyman >>> Subject: Re: [PATCH 87/88] Add configurable prefetch size for layoutget >>> >>> On 2011-06-09 08:07, Peng Tao wrote: >>>> Hi, Jim and Benny, >>>> >>>> On Thu, Jun 9, 2011 at 9:58 PM, Jim Rees <rees@xxxxxxxxx> wrote: >>>>> Benny Halevy wrote: >>>>> >>>>> Â> My understanding is that layoutget specifies a min and max, and the server >>>>> >>>>> ÂThere's a min. ÂWhat do you consider the max? >>>>> ÂWhatever gets into csa_fore_chan_attrs.ca_maxresponsesize? >>>>> >>>>> The spec doesn't say max, it says "desired." ÂI guess I assumed the server >>>>> wouldn't normally return more than desired. >>>> In fact server is returning "desired" length. The problem is that we >>>> call pnfs_update_layout in nfs_write_begin, and it will end up setting >>>> both minlength and length to page size. There is no space for client >>>> to collapse layoutget range in nfs_write_begin. >>>> >>> >>> That's a different issue. ÂWaiting with pnfs_update_layout to flush >>> time rather than write_begin if the whole page is written would help >>> sending a more meaningful desired range as well as avoiding needless >>> read-modify-writes in case the application also wrote the whole >>> preallocated block. >>> [PT] It is also the reason why we want to introduce layout prefetching, to get more segment than the page passed in nfs_write_begin. >>> >> >> Peng, I understand what you want to achieve but the proposed way >> just doesn't fly. The server knows better than the client its allocation policies >> and it knows better the combined workload of different client and possible >> conflicts between them therefore it should be making the ultimate decision >> about the actual segment sizes. >> [PT] Yes, you are right. Server should know combined workload of all clients and make its decision based on that. >> And it always has the right to return more than (or less than) specified in loga_length. >> >> That said, the client should indeed do its best to ask for the most appropriate >> segments size for its use and we should be making a better job at that. >> It's just that blindly asking for more is not a good strategy and requiring >> manual admin help to tune the clients is not acceptable. >> [PT] yeah, determing the most appropriate is always the hart part. Do you have any suggestions to that? > > 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 Err, that's another issue. Generic layer should really merge adjacent layout segments when necessary, instead of letting lookup code find out what are adjacent... > - 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 server is consistent about returning more/less than asked, it is an indicator that server is adjust the range automatically. Then client should stop using this algorithm and trust server behavior... > - 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 > >> >> Thanks, >> Tao > -- 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
