On Thu, Feb 24, 2022 at 10:41 PM Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote:
>
> Hi Amir-
>
> > On Feb 24, 2022, at 11:17 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
> >
> > The nfsd file cache table can be pretty large and its allocation
> > may require as many as 80 contigious pages.
> >
> > Employ the same fix that was employed for similar issue that was
> > reported for the reply cache hash table allocation several years ago
> > by commit 8f97514b423a ("nfsd: more robust allocation failure handling
> > in nfsd_reply_cache_init").
> >
> > Fixes: 65294c1f2c5e ("nfsd: add a new struct file caching facility to nfsd")
> > Link: https://lore.kernel.org/linux-nfs/e3cdaeec85a6cfec980e87fc294327c0381c1778.camel@xxxxxxxxxx/
> > Suggested-by: Jeff Layton <jlayton@xxxxxxxxxx>
> > Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx>
> > ---
> >
> > Since v1:
> > - Use kvcalloc()
> > - Use kvfree()
> >
> > fs/nfsd/filecache.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
>
> v2 passes some simple testing, so I've applied it to NFSD for-next.
> It should get 0-day and merge testing and is available for others
> to try out.
>
> I don't have anything that exercises low memory scenarios, though.
> Do you have anything like this to try?
Well, it is not low memory really it's fragmented memory.
I would try setting:
CONFIG_FAIL_PAGE_ALLOC=y
echo 5 > /sys/kernel/debug/fail_page_alloc/min-order
echo 100 > /sys/kernel/debug/fail_page_alloc/probability
and starting (or restarting) nfsd.
hoping that other large page allocations won't get in the way.
I gave it a shot, but couldn't figure out why nfsd4_files slab
is still there after stopping nfs-server service, meaning that
nfsd_file_cache_shutdown() was not called - I must be missing
something. I may play with this some more tomorrow.
Thanks,
Amir.
