Re: Linux/Pro -- clusters

[Jeff Garzik <jgarzik@mandrakesoft.com>]

Daniel Phillips wrote:
> On December 4, 2001 04:19 pm, Jeff Garzik wrote:
> > ug.  what's wrong with a single additional alloc for generic_ip?  [if a
> > filesystem needs to do multiple allocs post-conversion, somebody's doing
> > something wrong]
> 
> Single additional alloc -> twice as many allocs, two slabs, more cachelines
> dirty.  This was hashed out on fsdevel, though apparently not to everyone's
> satisfaction.
> 
> > Using generic_ip in its current form has the advantage of being able to
> > create a nicely-aligned kmem cache for your private inode data.
> 
> I don't see why that's hard with the combined struct.

The advantage of having two structs means that both struct inode and the
private info can be aligned nicely.  Yes it potentially wastes a tiny
bit more memory, but I challenge you to find an architecture where doing
this isn't a win.  In a couple cases I looked at, additional slabs are
not even necessary, as kmalloc's standard ones do the job quite well. 
'cat /proc/slabinfo' for a list of the sizes.

Note this only applies to inodes.  There aren't enough superblocks in a
running system to worry about doing anything but simple kmalloc on the
superblock private info (before assigning to generic_sbp).

	Jeff


-- 
Jeff Garzik      | Only so many songs can be sung
Building 1024    | with two lips, two lungs, and one tongue.
MandrakeSoft     |         - nomeansno