[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100105154047.GA18217@ZenIV.linux.org.uk>
Date: Tue, 5 Jan 2010 15:40:47 +0000
From: Al Viro <viro@...IV.linux.org.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Peter Zijlstra <peterz@...radead.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"minchan.kim@...il.com" <minchan.kim@...il.com>,
cl@...ux-foundation.org,
"hugh.dickins" <hugh.dickins@...cali.co.uk>,
Nick Piggin <nickpiggin@...oo.com.au>,
Ingo Molnar <mingo@...e.hu>
Subject: Re: [RFC][PATCH 6/8] mm: handle_speculative_fault()
On Tue, Jan 05, 2010 at 07:34:02AM -0800, Linus Torvalds wrote:
> The only other effects of delaying closing a file I can see are
>
> - the ETXTBUSY thing, but we don't need to delay _that_ part, so this may
> be a non-issue.
>
> - the actual freeing of the data on disk (ie people may expect that the
> last close really frees up the space on the filesystem). However, this
> is _such_ a subtle semantic thing that maybe nobody cares.
- a bunch of fs operations done from RCU callbacks. Including severely
blocking ones. As in "for minutes" in the most severe cases, and with
large numbers of objects involved. Can get very unpleasant...
--
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