From: Suparna Bhattacharya <suparna@in.ibm.com>
To: Andrew Morton <akpm@zip.com.au>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
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: Thu, 2 May 2002 14:24:41 +0530 [thread overview]
Message-ID: <20020502142441.A1668@in.ibm.com> (raw)
In-Reply-To: <3CCEF4CC.C56E31B8@zip.com.au>; from akpm@zip.com.au on Tue, Apr 30, 2002 at 12:47:24PM -0700
On Tue, Apr 30, 2002 at 12:47:24PM -0700, Andrew Morton wrote:
> Suparna Bhattacharya wrote:
> >
> > ...
> > > 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 ...)
> >
>
> I'd suggest that you go with the PG_partial thing for the
> follow-on pages.
>
> If you have a patch for crashdumps, and that patch is
> included in the main kernel, and it happens to rely on the
> addition of a new page flag well gee, that's a tiny change.
>
> Plus it only affects code paths in the `order > 0' case,
> which are rare.
>
> Plus you can independently use PG_partial to detect when
> someone is freeing pages from the wrong part of a higher-order
> allocation - that's a feature ;)
I guess the current check for page count during free should catch
this too in general. Possibly PG_partial would be more reliable
because the page count is more susceptible to modification as it
is touched more often ...
>
> An alternative is to just set PG_inuse against _all_ pages
> in rmqueue(), and clear PG_inuse against all pages in
> __free_pages_ok(). Which seems cleaner, and would fix other
> problems, I suspect.
This works well for us. If no one minds the extra flag, and it
is preferable to the option of initializing page count for
higher order pages, we'll go ahead and do this.
BTW, with PG_inuse, we can detect higher order pages too - ones
which are in use, but have a zero page count, i.e. PG_inuse +
zero page count == equivalent to == PG_partial. So it is possible
to locate the main page (or initial page) of the higher order
area, just as with PG_partial.
Likewise, with PG_partial, since this would be set and cleared
during alloc/free, we can figure out if a page is in use by
checking if page count is non-zero or this is a partial page,
i.e. PG_Partial | page_count > 0 == equivalent to == PG_inuse.
We can take any one way and define appropriate macros to
get both effects.
Regards
Suparna
>
> -
--
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-05-02 8:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20020429202446.A2326@in.ibm.com>
2002-04-29 17:40 ` Eric W. Biederman
2002-04-30 5:31 ` Suparna Bhattacharya
2002-04-30 14:05 ` Eric W. Biederman
2002-04-30 15:08 ` Suparna Bhattacharya
2002-04-30 19:47 ` Andrew Morton
2002-05-02 8:54 ` Suparna Bhattacharya [this message]
2002-05-02 13:08 ` Hugh Dickins
2002-05-02 21:13 ` Daniel Phillips
2002-05-03 12:24 ` Suparna Bhattacharya
2002-05-03 13:46 ` Hugh Dickins
2002-05-07 10:11 ` Suparna Bhattacharya
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=20020502142441.A1668@in.ibm.com \
--to=suparna@in.ibm.com \
--cc=akpm@zip.com.au \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox