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

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

 



-----Original Message-----
From: linux-nfs-owner@xxxxxxxxxxxxxxx [mailto:linux-nfs-owner@xxxxxxxxxxxxxxx] On Behalf Of Benny Halevy
Sent: Friday, June 10, 2011 8:48 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:02, 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:30 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 07:54, Peng Tao wrote:
>> On Thu, Jun 9, 2011 at 2:06 PM, Benny Halevy <bhalevy@xxxxxxxxxxx> wrote:
>>> On 2011-06-08 03:15, Peng Tao wrote:
>>>> On 6/8/11, Jim Rees <rees@xxxxxxxxx> wrote:
>>>>> Benny Halevy wrote:
>>>>>
>>>>>   NAK.
>>>>>   This affects all layout types.  In particular it is undesired
>>>>>   for write layouts that extend the file with the objects layout.
>>>>>   The server can extend the layout segments range
>>>>>   over what the client requested so why would the client
>>>>>   ask for artificially large layouts?
>>>>>
>>>>> This has actually been the subject of some debate over Thursday night
>>>>> beers.  The problem we're trying to solve is that the client is spending 98%
>>>>> of its time in layoutget.  This patch gives us something like a 10x
>>>>> speedup.  But many of us think it's not the right fix.  I suggest we discuss
>>>>> next week.
>>>>>
>>>
>>> Sure.
>>>
>>>>> But note that this patch doesn't change anything unless you set the sysctl.
>>>> there is a default value of 2M. maybe we can set it to page size by
>>>> default so other layout are not affected and block layout can let
>>>> users set it by hand if they care about performance. does this make
>>>> sense?
>>>
>>> If doing it at all why use a sysctl rather than a mount option?
>> The purpose of using a sysctl is to give client the ability to change
>> it on the fly. In theory, layout prefetching can benefit all layout
>> types. So the patch tries to solve it in the pnfs generic layer.
>>
> 
> But the need for this varies per-server and many times per application.
> Think sequential vs. random I/O.  Therefore a mount option would help
> tuning the behavior on a per-use basis.  Global behavior must be implemented
> using a dynamic algorithm that would take both the workload and the server
> observed behavior into account.
> [PT] Indeed. Dynamic algorithm is supposed to be able to solve all this. And it often takes longer to be designed/accepted. It has to prove to be better in most scenarios and does not hurt the left.

We need to find an acceptable solution to push this driver upstream.
I understand that developing a dynamic algorithm in the given time frame is
too big of a challenge, but hacking yet another client tunable is out of the
question either.   For testing in the Bakeathon I'd consider taking a DEVONLY version
of this patch that is enabled using a config option and defaults to zero to have no effect
in run-time until the sysctl is sets it differently.
But keep in mind this is not suitable for pushing upstream.
[PT] Thanks for your understanding. We truly want to solve the performance problem and are open to suggestions. And this will be a feature that benefits all layout types, am I right?

-Tao
--
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