Re: [RFC] fs/super.c: Why alloc_super use a static variable default_op?

[Al Viro]

On Wed, Jul 25, 2007 at 01:21:19PM +0800, rae l wrote:
 
> But there are also many other subsystems will do
> fs/dcache.c:
> void dput(struct dentry *dentry)
> 	if (dentry->d_op && dentry->d_op->d_delete) {
> Do you think it's worth optimizing it with a static d_op filled?
> 
> we can add a static variable to d_alloc and set its initial d_op to
> this static variable?
> struct dentry *d_alloc(struct dentry * parent, const struct qstr *name)

Try and compare...  It really depends - I suspect that for dentries the
situation differs since the case of ->d_op == NULL is *common*.  So
these checks actually might be a win - we are not unlikely to bail out
on the first one, without hitting the contents of *dentry->d_op.

For superblocks and inodes that is different - if we go looking for a method,
we *are* going to hit the method table anyway; it's not going to be NULL in
anything resembling a normal case.  So having the pointer to table initialized
that way is an obvious win - we don't really lose on space (savings in .text
at least balance the loss in .bss), we win on simpler logics and we actually
win by skipping the useless test.

How well would that pay for dentries...  Hell knows.  Space-wise it's the
same story, but we might end up doing extra work at accesses.  Try it - it's
not a hard patch to write, after all.
-
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/