From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by kanga.kvack.org (Postfix) with ESMTP id CF46E6B0055 for ; Wed, 3 Jun 2009 20:56:10 -0400 (EDT) Received: from makko.or.mcafeemobile.com by x35.xmailserver.org with [XMail 1.26 ESMTP Server] id for from ; Wed, 3 Jun 2009 20:55:48 -0400 Date: Wed, 3 Jun 2009 17:50:01 -0700 (PDT) From: Davide Libenzi Subject: Re: [PATCH 18/23] vfs: Teach epoll to use file_hotplug_lock In-Reply-To: Message-ID: References: <1243893048-17031-18-git-send-email-ebiederm@xmission.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org To: "Eric W. Biederman" Cc: Al Viro , Linux Kernel Mailing List , linux-pci@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Hugh Dickins , Tejun Heo , Alexey Dobriyan , Linus Torvalds , Alan Cox , Greg Kroah-Hartman , Nick Piggin , Andrew Morton , Christoph Hellwig , "Eric W. Biederman" List-ID: 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, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org