[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200709280747.06992.nickpiggin@yahoo.com.au>
Date: Fri, 28 Sep 2007 07:47:06 +1000
From: Nick Piggin <nickpiggin@...oo.com.au>
To: ric@....com, Andrea Arcangeli <andrea@...e.de>
Cc: Chris Mason <chris.mason@...cle.com>, Mark Lord <mlord@...ox.com>,
Valerie Henson <val.henson@...il.com>,
Christoph Hellwig <hch@...radead.org>,
Suparna Bhattacharya <suparna@...ibm.com>,
Andreas Dilger <adilger@...sterfs.com>,
Bob Bell <b_lkml@...bellsplace.com>,
Matthew Wilcox <matthew@....cx>, trond@...app.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] TASK_KILLABLE version 2
On Wednesday 26 September 2007 21:57, Ric Wheeler wrote:
> Bob Bell wrote:
> > On Sat, Sep 01, 2007 at 08:43:49PM -0600, Matthew Wilcox wrote:
> >> Here's the second version of TASK_KILLABLE. A few changes since
> >> version 1:
> >
> > <snip>
> >
> >> I obviously haven't covered every place that can result in a process
> >> sleeping uninterruptibly while attempting an operation. But sync_page
> >> (patch 4/5) covers about 90% of the times I've attempted to kill cat,
> >> and I hope that by providing the two examples, I can help other people
> >> to fix the cases that they find interesting.
> >
> > I've been testing this patch on my systems. It's working for me when
> > I read() a file. Asynchronous write()s seem okay, too. However,
> > synchronous writes (caused by either calling fsync() or fcntl() to
> > release a lock) prevent the process from being killed when the NFS
> > server goes down.
>
> After hearing again last month about how few people actually read every
> lkml thread, I wanted to point you all at this thread explicitly since
> it seems that we are getting somewhat close to having a forced unmount
> that actually is usable by real applications, something that we seem to
> have been talking about for many years ;-)
>
> With Matthew's original TASK_KILLABLE patch, we have a solution for a
> task read, but still have some holes (fsync & fcntl, others?) that need
> fixed as well for NFS clients.
>
> Is this patch going in the right direction?
FWIW, I do think it seems like a good idea to work towards better
interruptibility in various potentially long-blocking paths like these.
I think Andrea's recent work to solve some oom killer deadlocks
probably has some requirements in common with this patch.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists