[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.10.0906031708480.18001@makko.or.mcafeemobile.com>
Date: Wed, 3 Jun 2009 17:50:01 -0700 (PDT)
From: Davide Libenzi <davidel@...ilserver.org>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
cc: Al Viro <viro@...IV.linux.org.uk>,
Linux Kernel Mailing List <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>,
Nick Piggin <npiggin@...e.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Christoph Hellwig <hch@...radead.org>,
"Eric W. Biederman" <ebiederm@...stanetworks.com>
Subject: Re: [PATCH 18/23] vfs: Teach epoll to use file_hotplug_lock
On Wed, 3 Jun 2009, Eric W. Biederman wrote:
> What code are you talking about?
>
> To the open path a few memory writes and a smp_wmb. No atomics and no
> spin lock/unlocks.
>
> Are you complaining because I retain the file_list?
Sorry, did I overlook the patch? Weren't a couple of atomic ops and a spin
lock/unlock couple present in __dentry_open() (same sort of the release
path)?
And that's only like 5% of the code touched by the new special handling of
the file operations structure (basically, every f_op access ends up being
wrapped by two atomic ops and other extra code).
The question, that I'd like to reiterate is, is this stuff really needed?
Anyway, my complaint ends here and I'll let others evaluate if merging
this patchset is worth the cost.
- Davide
--
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