[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87ocftyfnh.fsf@basil.nowhere.org>
Date: Wed, 02 Jun 2010 10:58:42 +0200
From: Andi Kleen <andi@...stfloor.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Tim Chen <tim.c.chen@...ux.intel.com>,
linux-kernel@...r.kernel.org, Andi Kleen <ak@...ux.intel.com>,
Hugh Dickins <hughd@...gle.com>
Subject: Re: [PATCH v2 1/2] tmpfs: Quick token library to allow scalable retrieval of tokens from token jar
Andrew Morton <akpm@...ux-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@...ux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists