Re: optimize DNAME_INLINE_LEN

From: Andi Kleen (ak@suse.de)
Date: Thu Dec 13 2001 - 19:10:34 EST


On Thu, Dec 13, 2001 at 05:03:50PM -0700, Andreas Dilger wrote:
> On Dec 14, 2001 00:29 +0100, Andi Kleen wrote:
> > On Thu, Dec 13, 2001 at 04:07:06PM -0700, Andreas Dilger wrote:
> > > Alternately (also ugly) you could just define struct dentry the as now,
> > > but have a fixed size declaration for d_iname, like:
> > >
> > > #define DNAME_INLINE_MIN 16
> > >
> > > unsigned char d_iname[DNAME_INLINE_MIN];
> > Using [0] here would also work
>
> Well, not really. If we wanted to have a minimum size for the d_iname
> field, then if we declare it as zero and it just squeaks into a chacheline,
> then we may be stuck with 0 bytes of inline names, and _all_ names will
> be kmalloced.

That can be avoided by using a suitable formula for DNAME_INLINE_MIN

>
> > #define d_... has a similar problem => the potential to break previously
> > compiling source code.
>
> Again, not really. The #define d_... scheme would leave all of the fields
> in their original locations, just giving them new names within the named
> struct, and the defines would be the backwards compatible (and probably
> still preferrable) way to access these fields. I don't _think_ it would
> cause any compiler struct alignment issues to just put the same fields
> in another struct, but I could be wrong.

It won't help if any code is doing

void function()
{
        int d_name;
        ...
}

Preprocessor doesn't care about scopes so it would turn that into
an syntax error.

Anyways it is moot as Manfred's latest solution looks like the way to go.

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Dec 15 2001 - 21:00:27 EST