[pnfs] [PATCH] Increase maximum buffer size for layouts to 4 KB

Benny Halevy bhalevy at panasas.com
Wed Nov 29 03:42:04 EST 2006


Christoph Hellwig wrote:
> On Tue, Nov 28, 2006 at 12:43:42PM -0500, Dean Hildebrand wrote:
>> Benny Halevy wrote:
>>> William A. (Andy) Adamson wrote:
>>>   
>>>> hi benny
>>>>
>>>> should be ok.
>>>> are you expecting to have a large number of 4KB layouts? are you 
>>>> combining a bunch of layout ranges in the 4KB layout return?
>>>>     
>>> not necessarily...
>>> we just have big data structures.
>>> are we going to keep this static?
>>> If so I will check what;s the largest size we can anticipate
>>>
>>>
>>>   
>> The patch below definitely can't go in as is since 4kb layouts will need 
>> to come off the heap.  I'm assuming you are using a 64 bit machine or 
>> 8kb stacksize to make this patch work.
>>
>> Do we want to
>> a) malloc 4kb on every layoutget
>> b) use a layout buffer pool
>> c) malloc a buffer on every layoutget, but retrieve the size of the 
>> buffer (the max layout size) from the layout driver
>> d) other ways?
> 
> Even 1k on stack is probably yoo much.  So you should dynamially allocate
> it anyway.  I'm not familar enough with the implementation to know whether
> it's feasible, but it probably makes sense to control the allocation in
> the layour driver so we don't allocate more memory than nessecary.
> 

I agree.  I would go with option c. given the dynamic nature of the
layout structure.  In our case the layout size depends on how the object
is laid out and it should be taken from the xdr stream (it could then be
hashed into buffer pools of different sizes but malloc is doing that
already...).

Currently, we do allocate another buffer down at the layout driver and
we parse and copy the layout coming on the wire into this buffer.
We can save some memory and valuable bus cycles if we keep the xdr
buffer and point into it from our internal layout structure, eventually 
returning it when we free the layout (after return/revoke).  I don't
know how easy it is to do that...

Benny


More information about the pNFS mailing list