From mboxrd@z Thu Jan 1 00:00:00 1970 From: Max Kellermann Subject: Re: [PATCH] fs/namei: waiting for mutex during name lookups is "killable" Date: Mon, 28 Nov 2011 13:30:57 +0100 Message-ID: <20111128123056.GA19907@rabbit.intern.cm-ag> References: <20111128113918.23050.25938.stgit@rabbit.intern.cm-ag> <20111128121936.GR4387@parisc-linux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Matthew Wilcox Return-path: Content-Disposition: inline In-Reply-To: <20111128121936.GR4387@parisc-linux.org> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On 2011/11/28 13:19, Matthew Wilcox wrote: > On Mon, Nov 28, 2011 at 12:39:18PM +0100, Max Kellermann wrote: > > Use mutex_lock_killable() instead of mutex_lock() during name lookups, > > to allow killing the process while it's waiting. > > This is cool. Could you describe what situations this mutex gets held > for a user-noticable length of time, and how you tested this patch? I experienced lots of blocked unkillable processes in an environment that uses NFS mounts extensively. There seems to be a lot wrong with Linux's NFS client; it waits for RPC responses synchronously while the VFS layer holds mutexes, a behaviour that should be avoided. My patch does not try to address this core issue. Instead, it attempts to mitigate a nasty side effect. Most blocked processes were hanging inside stat(), in the code locations that my patch changes. After this patch, I could verify that the affected processes could be killed, instead of hanging in the task list until the one process holding the mutex would give up the RPC request. The patch has been in production on a few heavily loaded servers for nearly a week, and I did not observe any negative side effects. Max