From: "J. Bruce Fields" <bfields@fieldses.org>
To: Neil Brown <neilb@suse.de>
Cc: linux-nfs@vger.kernel.org, Kevin Coffman <kwc@citi.umich.edu>,
Steve Dickson <SteveD@redhat.com>
Subject: Re: [PATCH/RFC] svcgssd always sets an infinite expiry on authentication tokens etc.
Date: Tue, 2 Dec 2008 18:23:44 -0500 [thread overview]
Message-ID: <20081202232344.GM20616@fieldses.org> (raw)
In-Reply-To: <18740.50457.981544.21225-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
On Tue, Dec 02, 2008 at 04:18:17PM +1100, Neil Brown wrote:
> I have a report of an NFS server which runs out of kernel memory when
> it gets heave rpcsec_gss traffic (auth_sys doesn't trigger the
> problem so it must be gss related).
>
> From looking at /proc/slab_allocators it seems that the main user of
> memory is the rsc and rsi caches.
> It appears entries are inserted into these caches with an expiry of
> 'forever' so they grow but never shrink.
> We should fix this.
Yes, definitely a leak. But it's funny, I have a strong memory of a
conversation on one of these lists with someone who looked into this
problem and found that even with some silly artificial tests that
established as many contexts per second as possible, they weren't able
to see significant memory consumption--but I can't find the thread now.
Some limit on the size might also be nice depending on what the worst
case looks like with expiries of about a day.
--b.
>
> For the rsi (init) cache I assume the entry is only needed once so a
> short expiry of (say) one minute should be plenty.
> For the rsc (context) cache, the entry could be needed repeatedly
> during the lifetime of a 'session'. However eventually it will
> become stale and should be allowed to expire.
>
> I assume that if the kernel requests a particular entry a second
> time, an hour later, it will get the same answer - is that correct?
>
> In that case, setting the expiry to something largish seems
> appropriate.
>
> Hence the following patch (untested yet - but I will get it tested in
> due course).
>
> Does this seem reasonable?
prev parent reply other threads:[~2008-12-02 23:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-02 5:18 [PATCH/RFC] svcgssd always sets an infinite expiry on authentication tokens etc Neil Brown
[not found] ` <18740.50457.981544.21225-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2008-12-02 5:45 ` Kevin Coffman
[not found] ` <4d569c330812012145y2353bc9asd7a0c62fef42ed3a-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-12-02 16:04 ` Steve Dickson
[not found] ` <49355C78.6080607-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
2008-12-02 17:40 ` Kevin Coffman
[not found] ` <4d569c330812020940n3b8561fexfb97d89a7d5779a4-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-12-03 22:26 ` Kevin Coffman
2008-12-02 23:23 ` J. Bruce Fields [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081202232344.GM20616@fieldses.org \
--to=bfields@fieldses.org \
--cc=SteveD@redhat.com \
--cc=kwc@citi.umich.edu \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox