From: Dave Jones <davej@redhat.com>
To: Andi Kleen <ak@suse.de>
Cc: 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 11:52:41 -0400 [thread overview]
Message-ID: <20050513155241.GA3522@redhat.com> (raw)
In-Reply-To: <20050513132945.GB16088@wotan.suse.de>
Hi Andi,
On Fri, May 13, 2005 at 03:29:45PM +0200, Andi Kleen wrote:
> For memory (pfn_valid == 1) it would be more memory efficient to use a few bits
> in struct page->flags
Maybe.
> In general because there are lots of uses of "range lists" it would be better
> to put it as a library into lib.
Ditto.
> Coding style needs some work.
Yep.
> Too many printks.
At least whilst this is getting polished, its worth keeping these
around. Once its stable, I agree, they can go (or at least be
demoted to dprintk's). It seems that theres some problems with
the current code, so they're definitly useful..
for eg..
CMAP: cmap_request_range: 0xf8000000 - 0xf8100fff (1)
CMAP: cachings mismatch (4 != 1)
CMAP: cmap_request_range: 0xf8101000 - 0xf8101fff (1)
CMAP: cachings mismatch (4 != 1)
CMAP: cmap_request_range: 0xf8102000 - 0xf8301fff (1)
CMAP: cachings mismatch (4 != 1)
[drm:radeon_do_init_cp] *ERROR* could not find ioremap agp regions!
CMAP: cmap_release_range: 0xff8f0000 - 0xff96efff
CMAP: last user, freeing
CMAP: last user, freeing
CMAP: release_range successful!!
I'm not sure where that's coming from yet. There's also a few
failures to release regions which need to be double checked.
> I am not sure yet the cmaps don't need reference counting. For some
> cases (user space support) they probably will.
Asides from cmap_entry->count ?
Hmm, there doesn't seem to be anything guarding concurrent accesses
to that.
> Need user space support, e.g. using the existing ioctls for /proc/bus/pci/*
> (they are currently not implemented on i386/x86-64 but should with this)
> Then someone would need to change the X server to use this.
By hooking into ioremap(), we're getting this done automatically.
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV200 QW [Radeon 7500] (prog-if 00 [VGA])
Subsystem: PC Partner Limited RV200 QW [Radeon 7500 LE]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR+ FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (2000ns min), Cache Line Size 08
Interrupt: pin A routed to IRQ 225
Region 0: Memory at e8000000 (32-bit, prefetchable) [size=128M]
Region 1: I/O ports at c800 [size=256]
Region 2: Memory at ff8f0000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at ff8c0000 [disabled] [size=128K]
Capabilities: <available only to root>
(10:39:17:davej@dhcp83-2:~)$ grep e8000000 /proc/cachemap
0xe8000000 - 0xebffffff: 0x0004 1
Though I agree a userspace interface could be useful.
> Need to figure out if CMAP_ALLOW_OVERLAPPING should be set or not.
*nod*, and if it should, lose the ifdef completely.
> Probably need to go over the combining rule etc. with a fine comb
agreed. There's a bunch of errata on older CPUs that should probably
be checked too.
Thanks for the comments. I'm not working on this full-time, but
I'll continue to poke at it occasionally, especially if theres
interest from anyone else.
Dave
next prev parent reply other threads:[~2005-05-13 15:54 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
2005-05-13 14:35 ` Andi Kleen
2005-05-13 15:52 ` Dave Jones [this message]
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=20050513155241.GA3522@redhat.com \
--to=davej@redhat.com \
--cc=ak@suse.de \
--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.