[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1tz4tmxm8.fsf@fess.ebiederm.org>
Date: Sun, 12 Apr 2009 13:21:35 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Al Viro <viro@...IV.linux.org.uk>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
linux-mm@...ck.org, linux-fsdevel@...r.kernel.org,
Hugh Dickins <hugh@...itas.com>, Tejun Heo <tj@...nel.org>,
Alexey Dobriyan <adobriyan@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: [RFC][PATCH 0/9] File descriptor hot-unplug support
Al Viro <viro@...IV.linux.org.uk> writes:
> On Sat, Apr 11, 2009 at 09:49:36AM -0700, Eric W. Biederman wrote:
>
>> The fact that in the common case only one task ever accesses a struct
>> file leaves a lot of room for optimization.
>
> I'm not at all sure that it's a good assumption; even leaving aside e.g.
> several tasks sharing stdout/stderr, a bunch of datagrams coming out of
> several threads over the same socket is quite possible.
I have thought about this a little more and a solution to ensure this is
not a problem for code that has not opted in to this new functionality is
simple. Require uses that need it to set FMODE_REVOKE.
It is no extra code and it keeps the absolute worst case behavior for
existing code down an additional branch mispredict.
It is worth doing anyway because it cleans up the abstraction and makes
it clear where revoke is supported.
Eric
--
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