Messages in this thread | | | Subject | Re: [PATCH v2 1/2] tmpfs: Quick token library to allow scalable retrieval of tokens from token jar | From | Andi Kleen <> | Date | Wed, 02 Jun 2010 10:58:42 +0200 |
| |
Andrew Morton <akpm@linux-foundation.org> writes:
I am to blame for the "token jar" name.
> OK, thanks. But I'm still struggling a bit in understanding the > applicability. Where else might one use this? What particular > problem is it good at solving?
I wrote a similar scheme a long time ago for IP protocol ID allocation (but that code never ended up in mainline). Back then it was called "cookie jar" and you can actually still google for it :)
It can be used for pretty much anything where you have a global resource and want to hand it out to different CPUs, but still have a global limit that is enforced.
For example a file system could use it for accounting free space too.
In principle you could even use it for pids for example or other IDs.
> > I think the problem here is that you're using the term "token jar" as > if others already know what a token jar _is_. I guess I was asleep > during that compsci lecture, but google doesn't appear to know about > the term either. > > And from looking at the tmpfs caller, it appears that the token jar is > being used to speed up the access to a single `unsigned long > free_blocks'. Could we have used say a percpu_counter instead?
You need some synchronization, otherwise the accounting would not be exact and you could overflow. Yes you could open code it, but having it in a library is nicer.
That's what the token jar provides.
You grab some tokens out of the jar and to be fast take multiple in advance. And there's a watchman who forces you to give them back if you don't really need them all and they run low.
-Andi
-- ak@linux.intel.com -- Speaking for myself only.
| |