On Tue, 16 Jan 2007, Paul Menage wrote:
> On 1/15/07, Christoph Lameter <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
