From: Dave Hansen <haveblue@us.ibm.com>
To: Andi Kleen <ak@suse.de>
Cc: Dave Jones <davej@redhat.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
tripperda@nvidia.com
Subject: Re: [RFC] Cachemap for 2.6.12rc4-mm1. Was Re: [PATCH] enhance x86 MTRR handling
Date: Fri, 13 May 2005 07:24:22 -0700 [thread overview]
Message-ID: <1115994262.7129.22.camel@localhost> (raw)
In-Reply-To: <20050513132945.GB16088@wotan.suse.de>
On Fri, 2005-05-13 at 15:29 +0200, Andi Kleen wrote:
> > : x86-64 will need updating to also take advantage of this.
> > It may be able to just copy the i386 includes as-is, I've
> > not looked closely at the PAT related changes on x86-64 yet. Andi?
> >
> > : The list manipulation macros in mm/cachemap.c are a little fugly.
> >
> > Anything else ?
>
> For memory (pfn_valid == 1) it would be more memory efficient to use a few bits
> in struct page->flags
I think page->flags use should be limited to things that are relatively
performance-sensitive and arch-independent, mostly because we're running
out of them on 32-bit platforms, fast.
Each incremental use of page flags doesn't have any immediate storage
cost, but it's a serious pain when we run out, and having to bloat it to
a 64-bit value on 32-bit platforms wouldn't be very memory efficient,
either. :)
> In general because there are lots of uses of "range lists" it would be better
> to put it as a library into lib.
Either that, or something like "Dynamically allocated pageflags" would
be nice.
http://lwn.net/Articles/124332/
-- Dave
next prev parent reply other threads:[~2005-05-13 14:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-12 9:08 [PATCH] enhance x86 MTRR handling Jan Beulich
2005-05-12 16:18 ` Dave Jones
2005-05-12 17:02 ` David Addison
2005-05-12 21:41 ` [RFC] Cachemap for 2.6.12rc4-mm1. Was " Dave Jones
2005-05-13 13:29 ` Andi Kleen
2005-05-13 14:24 ` Dave Hansen [this message]
2005-05-13 14:35 ` Andi Kleen
2005-05-13 15:52 ` Dave Jones
2005-05-18 22:01 ` Terence Ripperda
2005-05-18 22:03 ` Andi Kleen
2005-05-18 22:15 ` Terence Ripperda
2005-05-18 22:42 ` Andi Kleen
2005-05-19 3:57 ` Randy Dunlap
2005-05-13 22:40 ` H. Peter Anvin
2005-05-13 23:23 ` Dave Jones
2005-05-13 23:36 ` H. Peter Anvin
2005-05-13 23:42 ` Dave Jones
2005-05-13 23:49 ` H. Peter Anvin
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=1115994262.7129.22.camel@localhost \
--to=haveblue@us.ibm.com \
--cc=ak@suse.de \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tripperda@nvidia.com \
/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.