From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Van Hensbergen Subject: Re: v9fs: VFS superblock operations (2.0-rc6) Date: Wed, 25 May 2005 09:41:35 -0500 Message-ID: References: <200505232225.j4NMPte1029529@ms-smtp-02-eri0.texas.rr.com> <84144f0205052400113c6f40fc@mail.gmail.com> <1116996843.9580.8.camel@localhost> Reply-To: Eric Van Hensbergen Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Cc: Pekka Enberg , linux-kernel@vger.kernel.org, v9fs-developer@lists.sourceforge.net, viro@parcelfarce.linux.theplanet.co.uk, linux-fsdevel@vger.kernel.org Return-path: To: Pekka J Enberg In-Reply-To: Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On 5/25/05, Pekka J Enberg wrote: > > > > Is this not the right way to use slabs? Should I just be using > > kmalloc/kcalloc? (Is that what you mean by drop the custom allocator?) > > You can create your own slab for known fixed-size objects (your > directory structure). Look at other filesystems for an example. They > usually create a cache for their inode_info structs. > > The problem with your approach on packet structure slab is that we > potentially get slabs with little or no activity. You would have to > write custom code to tear down unused slabs but now you've got something > that clearly does not belong in filesystem code. So yes, I think you'd > be better of using kmalloc()/kcalloc() for your packet structures. > Okay, I figured that since packet buffer sizes were "mostly" fixed by session configuration then slabs would be the way to go. But I see your point - I'll go ahead and convert all the packet buffers to kmalloc during the upcoming three-day weekend and try to push out a new release candidate early next week. -eric