On Wed, Oct 28, 2015 at 08:29:41PM -0700, Eric Dumazet wrote:
> But this is an optimization : If you do not use the initial dup2(), the
> fd array can be automatically expanded if needed (all slots are in use)
Whee...
> No locking change. files->file_lock is still taken.
>
> We only want to minimize time to find an empty slot.
Then I'd say that my variant is going to win. It *will* lead to
cacheline pingpong in more cases than yours, but I'm quite sure that
it will be a win as far as the total amount of cachelines accessed.
> The trick is to not start bitmap search at files->next_fd, but a random
> point. This is a win if we assume there are enough holes.
>
> low = start;
> if (low < files->next_fd)
> low = files->next_fd;
>
> res = -1;
> if (flags & O_FD_FASTALLOC) {
> random_point = pick_random_between(low, fdt->max_fds);
>
> res = find_next_zero_bit(fdt->open_fds, fdt->max_fds,
> random_point);
> /* No empty slot found, try the other range */
> if (res >= fdt->max_fds) {
> res = find_next_zero_bit(fdt->open_fds,
> low, random_point);
> if (res >= random_point)
> res = -1;
> }
> }
Have you tried to experiment with that in userland? I mean, emulate that
thing in normal userland code, count the cacheline accesses and drive it
with the use patterns collected from actual applications.
I can sit down and play with math expectations, but I suspect that it's
easier to experiment. It's nothing but an intuition (I hadn't seriously
done probability theory in quite a while, and my mathematical tastes run
more to geometry and topology anyway), but... I would expect it to degrade
badly when the bitmap is reasonably dense.
Note, BTW, that vmalloc'ed memory gets populated as you read it, and it's
not cheap - it's done via #PF triggered in kernel mode, with handler
noticing that the faulting address is in vmalloc range and doing the
right thing. IOW, if your bitmap is very sparse, the price of page faults
needs to be taken into account.
AFAICS, the only benefit of that thing is keeping dirtied cachelines far
from each other. Which might be a win overall, but I'm not convinced that
the rest won't offset the effect of that...
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
