Re: [PATCH v1 01/11] NFSD: Shrink size of struct nfsd4_copy_notify

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

 




> On Jul 25, 2022, at 10:19 AM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote:
> 
> Hi Chuck,
> 
> A general question: what's the rule for deciding whether to allocate
> statically or dynamically? I thought that "small" structures it's
> better to preallocate (statically) for performance reasons. Or is the
> idea here that copy_notify/copy are rare operations that instead they
> should be allocated dynamically and so that other operations doesn't
> consume more memory in nfsd4_op structure?

tl;dr: the latter. But it's not an issue of memory consumption, it's
that this whole struct is cleared with memset(0) for each incoming
RPC.

nfsd4_op is a union -- it takes the size of the largest args struct
in that union. Before copy offload was introduced, that was about
250 bytes. After, it is ~10x larger.

There are 8 nfsd4_op structs in an array in nfsd4_compoundargs.

The nfsd4_compoundargs structure is cleared by
svc_generic_init_request() before each NFSv4 RPC is executed.

So, in this case, the problem is 8 x 2KB = ~17KB to clear on
each RPC call for an operation that is quite infrequently
requested.

In NFSD, typically the execution context is amenable to GFP_KERNEL,
so it's generally OK to allocate dynamically for infrequently
requested operations.


--
Chuck Lever







[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