From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Mackall Subject: Re: [PATCH, RFC] Remove fasync() BKL usage, take 3325 Date: Wed, 28 Jan 2009 12:13:47 -0600 Message-ID: <1233166427.5202.907.camel@calx> References: <20090115153211.663df310@bike.lwn.net> <20090122065104.2787df2d.akpm@linux-foundation.org> <20090122203248.GA20159@infradead.org> <20090123045646.GK15750@one.firstfloor.org> <20090127165504.53ed7a2d.akpm@linux-foundation.org> <20090128031439.GA11025@redhat.com> <20090128173618.GA3174@infradead.org> <20090128104414.09aee3f9@bike.lwn.net> <20090128175541.GA7074@infradead.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20090128175541.GA7074-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Christoph Hellwig Cc: Jonathan Corbet , Oleg Nesterov , Andrew Morton , Andi Kleen , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, alan-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org List-Id: linux-api@vger.kernel.org On Wed, 2009-01-28 at 12:55 -0500, Christoph Hellwig wrote: > On Wed, Jan 28, 2009 at 10:44:14AM -0700, Jonathan Corbet wrote: > > If others disagree, and using bitops is not an idea which will fly, I'd > > sure like to know sooner rather than later. > > There are more than enough use cases that have large numbers of open > files (e.g. various high-end network servers). While it might not be > as sewer as for inodes I think it's really bad idea to do it for no > reason. Maybe we can just demote f_ep_lock to f_lock and share it? Or extend flags and have two independent bitlocks in it. This actually shrinks struct_file for most users. -- http://selenic.com : development and support for Mercurial and Linux -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html