On Mon 07-04-14 09:40:28, Andi Kleen wrote:
> Jan Kara <j...@suse.cz> writes:
> >
> > What we really need is a counter where we can better estimate counts
> > accumulated in the percpu part of it. As the counter approaches zero, it's
> > CPU overhead will have to become that of a single locked variable but when
> > the value of counter is relatively high, we want it to be fast as the
> > percpu one. Possibly, each CPU could "reserve" part of the value in the
> > counter (by just decrementing the total value; how large that part should
> > be really needs to depend to the total value of the counter and number of
> > CPUs - in this regard we really differ from classical percpu couters) and
> > allocate/free using that part. If CPU cannot reserve what it is asked for
> > anymore, it would go and steal from parts other CPUs have accumulated,
> > returning them to global pool until it can satisfy the allocation.
>
> That's a percpu_counter() isn't it? (or cookie jar)
Not quite. We could use __percpu_counter_add() to set batch size for each
operation depending on the current counter value. But still we don't want
any cpu-local count to go negative (as then we cannot rely on global
counter to give us a lower bound on number of free blocks). Also stealing
from different cpu needs to be implemented...
> The MM uses similar techniques.
Where exactly? I'd be happy to be inspired :).
Honza
--
Jan Kara <j...@suse.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
