From: Suparna Bhattacharya <suparna@in.ibm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-kernel@vger.kernel.org, marcelo@brutus.conectiva.com.br,
linux-mm@kvack.org
Subject: Re: [PATCH]Fix: Init page count for all pages during higher order allocs
Date: Tue, 30 Apr 2002 11:01:08 +0530 [thread overview]
Message-ID: <20020430110108.A1275@in.ibm.com> (raw)
In-Reply-To: <20020429202446.A2326@in.ibm.com> <m1r8ky1jzu.fsf@frodo.biederman.org>
On Mon, Apr 29, 2002 at 11:40:21AM -0600, Eric W. Biederman wrote:
> Suparna Bhattacharya <suparna@in.ibm.com> writes:
>
> > The call to set_page_count(page, 1) in page_alloc.c appears to happen
> > only for the first page, for order 1 and higher allocations.
> > This leaves the count for the rest of the pages in that block
> > uninitialised.
>
> Actually it should be zero.
>
> This is deliberate because high order pages should not be referenced by
> their partial pages.
That sounds reasonable provided there is a way to identify the main
page struct corresponding to an area that's part of a higher
order page.
> It might make sense to add a PG_large flag and
> then in the immediately following struct page add a pointer to the next
> page, so you can identify these pages by inspection. Doing something
> similar to the PG_skip flag.
Maybe different solutions could emerge for this in 2.4 and 2.5.
Even a PG_partial flag for the partial pages will enable us to
traverse back to the main page, and vice-versa to determine the
partial pages covered by the main page, without any additional
pointers. Is that an acceptable option for 2.4 ? (That's one
more page flag ...)
It would be good to have a way to determine the order directly
from the page struct, without such traversals, at least in 2.5.
>
> Beyond that I get nervous, that people will treat it as endorsement of
> doing a high order continuous allocation and then fragmenting the page.
I don't think it would amount to such an endorsement. It's just a matter
of replicating the settings from the main page to the partial pages -
which might be considered an alternate protocol, though a little
inefficient for really high orders. However, having the partial page
counts zeroed out probably helps as a safeguard in some situations in
view of the page count sanity checks. Or are there any scenarios where
you forsee a problem/breakage ?
Regards
Suparna
>
> Eric
WARNING: multiple messages have this Message-ID (diff)
From: Suparna Bhattacharya <suparna@in.ibm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-kernel@vger.kernel.org, marcelo@brutus.conectiva.com.br,
linux-mm@kvack.org
Subject: Re: [PATCH]Fix: Init page count for all pages during higher order allocs
Date: Tue, 30 Apr 2002 11:01:08 +0530 [thread overview]
Message-ID: <20020430110108.A1275@in.ibm.com> (raw)
In-Reply-To: <m1r8ky1jzu.fsf@frodo.biederman.org>; from ebiederm@xmission.com on Mon, Apr 29, 2002 at 11:40:21AM -0600
On Mon, Apr 29, 2002 at 11:40:21AM -0600, Eric W. Biederman wrote:
> Suparna Bhattacharya <suparna@in.ibm.com> writes:
>
> > The call to set_page_count(page, 1) in page_alloc.c appears to happen
> > only for the first page, for order 1 and higher allocations.
> > This leaves the count for the rest of the pages in that block
> > uninitialised.
>
> Actually it should be zero.
>
> This is deliberate because high order pages should not be referenced by
> their partial pages.
That sounds reasonable provided there is a way to identify the main
page struct corresponding to an area that's part of a higher
order page.
> It might make sense to add a PG_large flag and
> then in the immediately following struct page add a pointer to the next
> page, so you can identify these pages by inspection. Doing something
> similar to the PG_skip flag.
Maybe different solutions could emerge for this in 2.4 and 2.5.
Even a PG_partial flag for the partial pages will enable us to
traverse back to the main page, and vice-versa to determine the
partial pages covered by the main page, without any additional
pointers. Is that an acceptable option for 2.4 ? (That's one
more page flag ...)
It would be good to have a way to determine the order directly
from the page struct, without such traversals, at least in 2.5.
>
> Beyond that I get nervous, that people will treat it as endorsement of
> doing a high order continuous allocation and then fragmenting the page.
I don't think it would amount to such an endorsement. It's just a matter
of replicating the settings from the main page to the partial pages -
which might be considered an alternate protocol, though a little
inefficient for really high orders. However, having the partial page
counts zeroed out probably helps as a safeguard in some situations in
view of the page count sanity checks. Or are there any scenarios where
you forsee a problem/breakage ?
Regards
Suparna
>
> Eric
--
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/
next prev parent reply other threads:[~2002-04-30 5:31 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-29 14:54 [PATCH]Fix: Init page count for all pages during higher order allocs Suparna Bhattacharya
2002-04-29 17:40 ` Eric W. Biederman
2002-04-29 17:40 ` Eric W. Biederman
2002-04-30 5:31 ` Suparna Bhattacharya [this message]
2002-04-30 5:31 ` Suparna Bhattacharya
2002-04-30 14:05 ` Eric W. Biederman
2002-04-30 14:05 ` Eric W. Biederman
2002-04-30 15:08 ` Suparna Bhattacharya
2002-04-30 15:08 ` Suparna Bhattacharya
2002-04-30 19:47 ` Andrew Morton
2002-04-30 19:47 ` Andrew Morton
2002-05-02 8:54 ` Suparna Bhattacharya
2002-05-02 8:54 ` Suparna Bhattacharya
2002-05-02 13:08 ` Hugh Dickins
2002-05-02 13:08 ` Hugh Dickins
2002-05-02 21:13 ` Daniel Phillips
2002-05-02 21:13 ` Daniel Phillips
2002-05-03 12:24 ` Suparna Bhattacharya
2002-05-03 12:24 ` Suparna Bhattacharya
2002-05-03 13:46 ` Hugh Dickins
2002-05-03 13:46 ` Hugh Dickins
2002-05-07 10:11 ` Suparna Bhattacharya
2002-05-07 10:11 ` Suparna Bhattacharya
2002-05-07 7:34 ` Bharata B Rao
2002-05-07 7:34 ` Bharata B Rao
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=20020430110108.A1275@in.ibm.com \
--to=suparna@in.ibm.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=marcelo@brutus.conectiva.com.br \
/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.