All of lore.kernel.org
 help / color / mirror / Atom feed
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/

  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.