From: Pavel Machek <pavel@ucw.cz>
To: Lukas Hejtmanek <xhejtman@ics.muni.cz>
Cc: linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, salvet@ics.muni.cz
Subject: Re: Deadlock in NFSv4 in all kernels
Date: Mon, 24 May 2010 23:24:23 +0200 [thread overview]
Message-ID: <20100524212422.GA1286@ucw.cz> (raw)
In-Reply-To: <20100507153920.GP28167@ics.muni.cz>
Hi!
> I encountered the following problem. We use short expiration time for
> kerberos contexts created by rpc.gssd (some patches were included in mainline
> nfs-utils). In particular, we use 120secs expiration time.
>
> Now, I run application that eats 80% of available RAM. Then I run 10 parallel
> dd processes that write data into NFS4 volume with sec=krb5.
>
> As soon as the kerberos context expires (i.e., up to 120 secs), the whole
> system gets stuck in do_page_fault and succesive functions. It is because
> there is no free memory in kernel, all free memory is used as cache for NFS4
> (due to dd traffic), kernel ask NFS to write back its pages but NFS cannot do
> anything as it is missing valid context. NFS contacts rpc.gssd to provide
> a renewed context, the rpc.gssd does not provide the context as it needs some memory
> to scan /tmp for a ticket. I.e., it deadlocks.
>
> Longer context expiration time is no real solution as it only makes the
> deadlock less often.
>
> Any ideas what can be done here? (Please cc me.) We could preallocate some
> memory in rpc.gssd and use mlockall but not sure whether this proctects also
> kernel malloc for things related to rpc.gssd and context creation (new file
> descriptors and so on).
>
> This is seen in 2.6.32 kernel but most probably this is related to all kernel
> versions.
Seems like pretty fundamental problem in nfs :-(. Limiting writeback
caches for nfs, so that system has enough memory to perform rpc calls
with the rest might do the trick, but...
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2010-05-24 21:24 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-07 15:39 Deadlock in NFSv4 in all kernels Lukas Hejtmanek
2010-05-07 15:39 ` Lukas Hejtmanek
2010-05-24 21:24 ` Pavel Machek [this message]
2010-05-25 12:28 ` Trond Myklebust
2010-05-25 12:58 ` Lukas Hejtmanek
2010-05-25 13:39 ` Trond Myklebust
2010-05-25 13:39 ` Trond Myklebust
2010-05-25 14:07 ` Zdenek Salvet
2010-05-25 14:07 ` Zdenek Salvet
2010-05-25 17:10 ` Sunil Mushran
2010-05-25 17:10 ` Sunil Mushran
2010-05-25 13:45 ` William A. (Andy) Adamson
2010-05-25 13:45 ` William A. (Andy) Adamson
2010-05-25 14:02 ` Lukas Hejtmanek
2010-05-25 14:02 ` Lukas Hejtmanek
2010-05-25 14:10 ` William A. (Andy) Adamson
2010-05-25 14:10 ` William A. (Andy) Adamson
2010-05-25 14:29 ` Trond Myklebust
2010-05-25 14:29 ` Trond Myklebust
2010-05-25 14:04 ` Trond Myklebust
2010-05-25 14:04 ` Trond Myklebust
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=20100524212422.GA1286@ucw.cz \
--to=pavel@ucw.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=salvet@ics.muni.cz \
--cc=xhejtman@ics.muni.cz \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.