Messages in this thread | | | Date | Sat, 8 May 2004 21:25:37 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: dentry bloat. |
| |
On Sat, 8 May 2004, Andrew Morton wrote: > > I think that'll crash. DNAME_INLINE_LEN_MIN is the *minimum* storage in > the dentry. The actual storage is assumed to be DNAME_INLINE_LEN and the > patch doesn't change that value.
It doesn't need to, the value is correct.
> The calculation of DNAME_INLINE_LEN assumes that slab padded the dentry out > to the next cacheline.
No it doesn't. It's just:
#define DNAME_INLINE_LEN (sizeof(struct dentry)-offsetof(struct dentry,d_iname))
which is always right.
It used to assume the padding because of the "____cacheline_aligned" on the struct dentry, which obviously also padded out the "sizeof()". But since I removed that, DNAME_INLINE_LEN is still correct.
NOTE! It's absolutely true that DNAME_INLINE_LEN may still be different from DNAME_INLINE_LEN_MIN. In particular, if something inside the struct makes the alignment of "struct dentry" be bigger than the offset of the last field, then DNAME_INLINE_LEN will be different from (bigger than) DNAME_INLINE_LEN.
It's just that with current architectures, I don't believe that will happen in practice. But I left it as-is, because at least in theory it could happen.
Linus - 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/
| |