From: Glauber Costa <glommer@parallels.com>
To: David Rientjes <rientjes@google.com>
Cc: Pekka Enberg <penberg@kernel.org>,
linux-mm@kvack.org, Cristoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@cs.helsinki.fi>,
Michal Hocko <mhocko@suse.cz>,
Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Suleiman Souhlal <suleiman@google.com>
Subject: Re: [PATCH 4/4] don't do __ClearPageSlab before freeing slab page.
Date: Thu, 21 Jun 2012 12:13:38 +0400 [thread overview]
Message-ID: <4FE2D7B2.8060204@parallels.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1206210103350.31077@chino.kir.corp.google.com>
On 06/21/2012 12:04 PM, David Rientjes wrote:
> On Thu, 21 Jun 2012, Glauber Costa wrote:
>
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index 6092f33..fdec73e 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -698,8 +698,10 @@ static bool free_pages_prepare(struct page *page, unsigned int order)
>>
>> if (PageAnon(page))
>> page->mapping = NULL;
>> - for (i = 0; i < (1 << order); i++)
>> + for (i = 0; i < (1 << order); i++) {
>> + __ClearPageSlab(page + i);
>> bad += free_pages_check(page + i);
>> + }
>> if (bad)
>> return false;
>>
>> @@ -2561,6 +2563,7 @@ EXPORT_SYMBOL(get_zeroed_page);
>> void __free_pages(struct page *page, unsigned int order)
>> {
>> if (put_page_testzero(page)) {
>> + __ClearPageSlab(page);
>> if (order == 0)
>> free_hot_cold_page(page, 0);
>> else
>
> These are called from a number of different places that has nothing to do
> with slab so it's certainly out of place here. Is there really no
> alternative way of doing this?
Well, if the requirement is that we must handle this from the page
allocator, how else should I know if I must call the corresponding free
functions ?
Also note that other bits are tested inside the page allocator as well,
such as MLock.
I saw no other way, but if you have suggestions, I'd be open to try
them, of course.
>> diff --git a/mm/slab.c b/mm/slab.c
>> index cb6da05..3e578fc 100644
>> --- a/mm/slab.c
>> +++ b/mm/slab.c
>> @@ -1821,11 +1821,6 @@ static void kmem_freepages(struct kmem_cache *cachep, void *addr)
>> else
>> sub_zone_page_state(page_zone(page),
>> NR_SLAB_UNRECLAIMABLE, nr_freed);
>> - while (i--) {
>> - BUG_ON(!PageSlab(page));
>> - __ClearPageSlab(page);
>> - page++;
>> - }
>> if (current->reclaim_state)
>> current->reclaim_state->reclaimed_slab += nr_freed;
>> free_pages((unsigned long)addr, cachep->gfporder);
>
> And we lose this validation in slab.
>
> I'm hoping there's an alternative.
The validation can stay, if you would prefer. We still expect the page
to be PageSlab at this point, so we can test for it, and only clear later.
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-06-21 8:16 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-20 20:59 [PATCH 0/4] cache-specific changes for memcg (preparation) Glauber Costa
2012-06-20 20:59 ` [PATCH 1/4] slab: rename gfpflags to allocflags Glauber Costa
2012-06-21 7:53 ` David Rientjes
2012-06-20 20:59 ` [PATCH 2/4] Wipe out CFLGS_OFF_SLAB from flags during initial slab creation Glauber Costa
2012-06-21 7:59 ` David Rientjes
2012-06-20 20:59 ` [PATCH 3/4] slab: move FULL state transition to an initcall Glauber Costa
2012-06-21 8:01 ` David Rientjes
2012-07-02 10:57 ` Pekka Enberg
2012-06-20 20:59 ` [PATCH 4/4] don't do __ClearPageSlab before freeing slab page Glauber Costa
2012-06-21 8:04 ` David Rientjes
2012-06-21 8:13 ` Glauber Costa [this message]
2012-06-21 11:04 ` Kamezawa Hiroyuki
2012-06-21 11:14 ` Glauber Costa
2012-06-21 20:24 ` Glauber Costa
2012-07-03 18:42 ` Christoph Lameter
2012-07-03 18:40 ` 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=4FE2D7B2.8060204@parallels.com \
--to=glommer@parallels.com \
--cc=cl@linux.com \
--cc=hannes@cmpxchg.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=penberg@cs.helsinki.fi \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=suleiman@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;
as well as URLs for NNTP newsgroup(s).