Re: [RFC 8/8] Reduce inode memory usage for systems with a highMAX_NUMNODES

[Christoph Lameter]

On Tue, 16 Jan 2007, Paul Menage wrote:

> On 1/15/07, Christoph Lameter <clameter@xxxxxxx> wrote:
> > 
> > This solution may be a bit hokey. I tried other approaches but this
> > one seemed to be the simplest with the least complications. Maybe someone
> > else can come up with a better solution?
> 
> How about a 64-bit field in struct inode that's used as a bitmask if
> there are no more than 64 nodes, and a pointer to a bitmask if there
> are more than 64 nodes. The filesystems wouldn't need to be involved
> then, as the bitmap allocation could be done in the generic code.

How would we decide if there are more than 64 nodes? Runtime or compile 
time?

If done at compile time then we will end up with a pointer to an unsigned 
long for a system with <= 64 nodes. If we allocate the nodemask via 
kmalloc then we will always end up with a mininum allocation size of 64 
bytes. Then there is the slab management overhead which will increase 
overhead closer to the 128 byte wastage that we have now. So its likely 
not worth it. There are some additional complications since there is a 
need to free and allocate the nodemask during inode initialization and 
disposal.

If the decision to allocate a node mask is made at run time then it gets 
even more complex. And we still have the same troubling issues with the 
64 byte mininum allocation by the slab.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/