Messages in this thread | | | Date | Wed, 25 Jul 2007 07:39:53 +0100 | From | Al Viro <> | Subject | Re: [RFC] fs/super.c: Why alloc_super use a static variable default_op? |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |