From: Minchan Kim <minchan@kernel.org>
To: Christoph Lameter <cl@linux.com>
Cc: Minchan Kim <minchan@kernel.org>,
Namhyung Kim <namhyung.kim@lge.com>,
Pekka Enberg <penberg@kernel.org>, Matt Mackall <mpm@selenic.com>,
Namhyung Kim <namhyung@gmail.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH -next] slub: set PG_slab on all of slab pages
Date: Tue, 6 Mar 2012 10:16:24 +0900 [thread overview]
Message-ID: <20120306011624.GA14274@barrios> (raw)
In-Reply-To: <alpine.DEB.2.00.1203050845380.11722@router.home>
Hi Christoph,
On Mon, Mar 05, 2012 at 08:48:33AM -0600, Christoph Lameter wrote:
> On Sun, 4 Mar 2012, Minchan Kim wrote:
>
> > I read this thread and I feel the we don't reach right point.
> > I think it's not a compound page problem.
> > We can face above problem where we allocates big order page without __GFP_COMP
> > and free middle page of it.
>
> Yes we can do that and doing such a thing seems to be more legitimate
> since one could argue that the user did not request an atomic allocation
> unit from the page allocator and therefore the freeing of individual
> pages in that group is permissible. If memory serves me right we do that
> sometimes.
To be leitimate, user have to handle subpages's ref counter well.
But I think it's not desirable. If user want it, he should use
split_page instead of modifying ref counter directly.
>
> However if compound pages are requested then such an atomic allocation
> unit *was* requested and the page allocator should not allow to free
> individual pages.
Yes. In fact, I am not sure this problem is related to compound page.
If it is compound page, tail page's ref count should be zero.
When user calls __free_pages in tail page by mistake, it should not pass
into __free_pages_ok but reference count would be underflow.
Later, when head page is freed, we could catch it in free_pages_check.
So I had a question to Namhyung that he can see bad page message by PG_slab when he uses SLUB
with his patch. If the problem still happens, something seems to modify tail page's ref count
directly without get_page. It's apparently BUG.
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Minchan Kim <minchan@kernel.org>
To: Christoph Lameter <cl@linux.com>
Cc: Minchan Kim <minchan@kernel.org>,
Namhyung Kim <namhyung.kim@lge.com>,
Pekka Enberg <penberg@kernel.org>, Matt Mackall <mpm@selenic.com>,
Namhyung Kim <namhyung@gmail.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH -next] slub: set PG_slab on all of slab pages
Date: Tue, 6 Mar 2012 10:16:24 +0900 [thread overview]
Message-ID: <20120306011624.GA14274@barrios> (raw)
In-Reply-To: <alpine.DEB.2.00.1203050845380.11722@router.home>
Hi Christoph,
On Mon, Mar 05, 2012 at 08:48:33AM -0600, Christoph Lameter wrote:
> On Sun, 4 Mar 2012, Minchan Kim wrote:
>
> > I read this thread and I feel the we don't reach right point.
> > I think it's not a compound page problem.
> > We can face above problem where we allocates big order page without __GFP_COMP
> > and free middle page of it.
>
> Yes we can do that and doing such a thing seems to be more legitimate
> since one could argue that the user did not request an atomic allocation
> unit from the page allocator and therefore the freeing of individual
> pages in that group is permissible. If memory serves me right we do that
> sometimes.
To be leitimate, user have to handle subpages's ref counter well.
But I think it's not desirable. If user want it, he should use
split_page instead of modifying ref counter directly.
>
> However if compound pages are requested then such an atomic allocation
> unit *was* requested and the page allocator should not allow to free
> individual pages.
Yes. In fact, I am not sure this problem is related to compound page.
If it is compound page, tail page's ref count should be zero.
When user calls __free_pages in tail page by mistake, it should not pass
into __free_pages_ok but reference count would be underflow.
Later, when head page is freed, we could catch it in free_pages_check.
So I had a question to Namhyung that he can see bad page message by PG_slab when he uses SLUB
with his patch. If the problem still happens, something seems to modify tail page's ref count
directly without get_page. It's apparently BUG.
next prev parent reply other threads:[~2012-03-06 1:16 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-29 8:54 [PATCH -next] slub: set PG_slab on all of slab pages Namhyung Kim
2012-02-29 8:54 ` Namhyung Kim
2012-02-29 15:24 ` Christoph Lameter
2012-02-29 15:24 ` Christoph Lameter
2012-03-01 7:30 ` Namhyung Kim
2012-03-01 7:30 ` Namhyung Kim
2012-03-01 15:03 ` Christoph Lameter
2012-03-01 15:03 ` Christoph Lameter
2012-03-02 7:12 ` Namhyung Kim
2012-03-02 7:12 ` Namhyung Kim
2012-03-02 16:13 ` Christoph Lameter
2012-03-02 16:13 ` Christoph Lameter
2012-03-04 10:34 ` Minchan Kim
2012-03-04 10:34 ` Minchan Kim
2012-03-05 8:42 ` Namhyung Kim
2012-03-05 8:42 ` Namhyung Kim
2012-03-05 10:59 ` Minchan Kim
2012-03-05 10:59 ` Minchan Kim
2012-03-05 14:48 ` Christoph Lameter
2012-03-05 14:48 ` Christoph Lameter
2012-03-06 1:16 ` Minchan Kim [this message]
2012-03-06 1:16 ` Minchan Kim
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=20120306011624.GA14274@barrios \
--to=minchan@kernel.org \
--cc=cl@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mpm@selenic.com \
--cc=namhyung.kim@lge.com \
--cc=namhyung@gmail.com \
--cc=penberg@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.