From: Suparna Bhattacharya <suparna@in.ibm.com>
To: Andrew Morton <akpm@zip.com.au>
Cc: lkml <linux-kernel@vger.kernel.org>,
Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [brokenpatch] page accounting
Date: Thu, 11 Apr 2002 20:43:47 +0530 [thread overview]
Message-ID: <3CB5A82B.80C942A0@in.ibm.com> (raw)
In-Reply-To: <3CB41BA7.DAC3A785@zip.com.au>
Andrew Morton wrote:
>
> The patch implements per-CPU accounting of the global number
> of locked, diry and pagecache pages.
>
> -#define PG_locked 0 /* Page is locked. Don't touch. */
> +
> +/*
> + * Don't use the *_dontuse flags. Use the macros. Otherwise
> + * you'll break locked- and dirty-page accounting.
> + */
> +#define PG_locked_dontuse 0 /* Page is locked. Don't touch. */
> #define PG_error 1
> #define PG_referenced 2
> #define PG_uptodate 3
> -#define PG_dirty 4
> +#define PG_dirty_dontuse 4
> #define PG_unused 5
> #define PG_lru 6
> #define PG_active 7
> -#define PG_slab 8
> -#define PG_skip 10
> +#define PG_slab 8 /* kill me if needed: slab debug */
A little plea for mercy for this tiny bit :)
Could we keep PG_slab around unless its really causing trouble ? It
makes life easier for some things we do ... Also its rather nice that
today as a result of a wide usage of
slab infrastructure in the kernel, one can easily/directly interpret the
contents of
almost any arbitrary memory location in the kernel, if its a slab page,
as one knows what type of data it contains.
> +#define PG_skip 10 /* kill me now: obsolete */
> #define PG_highmem 11
> #define PG_checked 12 /* kill me in 2.5.<early>. */
> #define PG_arch_1 13
> #define PG_reserved 14
> #define PG_launder 15 /* written out by VM pressure.. */
> -
> #define PG_private 16 /* Has something at ->private */
>
next prev parent reply other threads:[~2002-04-11 15:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-10 11:01 [brokenpatch] page accounting Andrew Morton
2002-04-10 12:56 ` Rusty Russell
2002-04-11 15:13 ` Suparna Bhattacharya [this message]
2002-04-11 18:04 ` Andrew Morton
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=3CB5A82B.80C942A0@in.ibm.com \
--to=suparna@in.ibm.com \
--cc=akpm@zip.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
/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.