On Fri, 13 Apr 2007 15:08:38 -0400
Jeff Layton <[EMAIL PROTECTED]> wrote:
> >
> > ino_t iunique(struct super_block *sb, ino_t max_reserved)
> > {
> > static ino_t counter;
> > struct inode *inode;
> > struct hlist_head * head;
> > ino_t res;
> >
> > spin_lock(&inode_lock);
> > do {
> > if (counter <= max_reserved)
> > counter = max_reserved + 1;
> > res = counter++;
> > head = inode_hashtable + hash(sb, res);
> > inode = find_inode_fast(sb, head, res);
> > } while (inode != NULL);
> > spin_unlock(&inode_lock);
> >
> > return res;
> > }
> >
> > The counter-vs-max_reserved test can be moved outside the loop, can't it?
> >
>
> No. If the counter wraps while we're looping, then we'll need to skip
> past the "reserved" inode numbers. So we need to check this on every
> loop iteration.
oh.
(wonders why alpha and s390 use unsigned int for ino_t while everyone
else uses unsigned long)
> We could potentially put that in an "unlikely" if you
> think that would be better.
Doubt if it'd make much difference.
> > Shouldn't counter be per-sb?
>
> I doubt it really matters too much, but it could potentially be more
> efficient to do that, especially after a wraparound on the counter. It
> might be reasonable to make new_inode use a per-sb counter as well. Do
> you think it's worth respinning?
Well, that'd be a separate patch. Sometime, if you're keen.
If that function is ever a performance problem, it'll be an awful
performance problem and we'd need to so something smarter than
a linear search - an idr tree, for example.
-
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/
