From: Glauber Costa <glommer@parallels.com>
To: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>,
linux-mm@kvack.org, David Rientjes <rientjes@google.com>,
Matt Mackall <mpm@selenic.com>
Subject: Re: [RFC] SL[AUO]B common code 5/9] slabs: Common definition for boot state of the slab allocators
Date: Thu, 17 May 2012 13:38:36 +0400 [thread overview]
Message-ID: <4FB4C71C.6040906@parallels.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1205160928490.25603@router.home>
On 05/16/2012 06:31 PM, Christoph Lameter wrote:
>> There are a couple of places where that test seems to be okay (I remember 1 in
>> > the slub), but at least for the "FULL" test here, we should be testing>=
>> > FULL.
>> >
>> > Also, I don't like the name FULL too much, since I do intend to add a new one
>> > soon (MEMCG, as you can see in my series)
> Ok. Why would memcg need an additional state?
Please refer to my patchset for the full story.
I add state both to the slab and to the slub for that.
But in summary, it is not unlike the "SYSFS" state: we depend on
something else outside of the slab domain to be ready before we can proceed.
Specifically, we need to register each cache with an index. And for
that, we use idr/ida. When it is ready, we run code to register indexes
for all caches that are already available. After that, we just grab an
index right away - much like sysfs state for aliases.
>> > Since we are using slab-specific states like PARTIAL_L3 here, maybe we can use
>> > slub's like SYSFS here with no problem.
> Sure. I thought there would only be special states before UP.
>
>> > If we stick to>= and<= whenever needed, that should reflect a lot better
>> > what the algorithm is really doing
> How so?
In the sense that we very rarely want to do some action *at a specific
moment*. Most of the time we want to separate the world into before and
after a state. We test == instead of <= and >=, and it happens to work
because of the specific order of things, which are subject to change in
a rework or another...
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-05-17 9:40 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-14 20:15 [RFC] SL[AUO]B common code 0/9] Sl[auo]b: Common functionality V1 Christoph Lameter
2012-05-14 20:15 ` [RFC] SL[AUO]B common code 1/9] [slob] define page struct fields used in mm_types.h Christoph Lameter
2012-05-16 7:31 ` Glauber Costa
2012-05-16 14:26 ` Christoph Lameter
2012-05-16 15:38 ` Christoph Lameter
2012-05-17 9:41 ` Glauber Costa
2012-05-17 14:09 ` Christoph Lameter
2012-05-14 20:15 ` [RFC] SL[AUO]B common code 2/9] [slab]: Use page struct fields instead of casting Christoph Lameter
2012-05-16 7:52 ` Glauber Costa
2012-05-14 20:15 ` [RFC] SL[AUO]B common code 3/9] Extract common fields from struct kmem_cache Christoph Lameter
2012-05-16 7:59 ` Glauber Costa
2012-05-16 14:28 ` Christoph Lameter
2012-05-16 15:41 ` Christoph Lameter
[not found] ` <alpine.LFD.2.02.1205160943180.2249@tux.localdomain>
[not found] ` <alpine.DEB.2.00.1205160922520.25512@router.home>
[not found] ` <alpine.LFD.2.02.1205181221570.3899@tux.localdomain>
2012-05-18 13:57 ` Christoph Lameter
2012-05-14 20:15 ` [RFC] SL[AUO]B common code 4/9] slabs: Extract common code for kmem_cache_create Christoph Lameter
2012-05-14 20:15 ` [RFC] SL[AUO]B common code 5/9] slabs: Common definition for boot state of the slab allocators Christoph Lameter
2012-05-16 8:19 ` Glauber Costa
2012-05-16 14:31 ` Christoph Lameter
2012-05-17 9:38 ` Glauber Costa [this message]
2012-05-17 14:07 ` Christoph Lameter
2012-05-17 14:08 ` Glauber Costa
2012-05-17 14:16 ` Christoph Lameter
2012-05-17 14:19 ` Glauber Costa
2012-05-17 14:27 ` Christoph Lameter
2012-05-16 15:44 ` Christoph Lameter
2012-05-14 20:15 ` [RFC] SL[AUO]B common code 6/9] slabs: Use a common mutex definition Christoph Lameter
2012-05-16 8:34 ` Glauber Costa
2012-05-16 14:32 ` Christoph Lameter
2012-05-14 20:15 ` [RFC] SL[AUO]B common code 7/9] slabs: Move kmem_cache_create mutex handling to common code Christoph Lameter
2012-05-16 10:15 ` Glauber Costa
2012-05-14 20:15 ` [RFC] SL[AUO]B common code 8/9] slabs: list addition move to slab_common Christoph Lameter
2012-05-16 10:09 ` Glauber Costa
2012-05-16 14:33 ` Christoph Lameter
2012-05-17 9:39 ` Glauber Costa
2012-05-17 14:09 ` Christoph Lameter
2012-05-14 20:15 ` [RFC] SL[AUO]B common code 9/9] slabs: Extract a common function for kmem_cache_destroy Christoph Lameter
2012-05-16 8:08 ` [RFC] SL[AUO]B common code 0/9] Sl[auo]b: Common functionality V1 Glauber Costa
2012-05-16 14:28 ` Christoph Lameter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FB4C71C.6040906@parallels.com \
--to=glommer@parallels.com \
--cc=cl@linux.com \
--cc=linux-mm@kvack.org \
--cc=mpm@selenic.com \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox