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

From: Chuck Lever III <chuck.lever@oracle.com>
To: Olga Kornievskaia <aglo@umich.edu>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v1 01/11] NFSD: Shrink size of struct nfsd4_copy_notify
Date: Mon, 25 Jul 2022 14:36:36 +0000	[thread overview]
Message-ID: <92DBE2E3-ACA3-4EBF-9975-E561696CF15F@oracle.com> (raw)
In-Reply-To: <CAN-5tyGJFpBum6ZtO=9r0o7yNf1tsgNSEZBPJWj_qJUyLNtBWQ@mail.gmail.com>

> On Jul 25, 2022, at 10:19 AM, Olga Kornievskaia <aglo@umich.edu> 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