public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Andi Kleen <ak@muc.de>
Cc: Terence Ripperda <tripperda@nvidia.com>, linux-kernel@vger.kernel.org
Subject: Re: PAT support
Date: 14 Apr 2004 22:11:01 -0600	[thread overview]
Message-ID: <m1fzb56fu2.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <m3n05gu4o2.fsf@averell.firstfloor.org>

Andi Kleen <ak@muc.de> writes:

> Terence Ripperda <tripperda@nvidia.com> writes:
> 
> Hi Terence,
> 
> > this current patch includes the original PAT support and the new
> > cachemap mechanism. note that the cachemap mechanism does not
> > actually change any caching attributes, it only keeps track of the
> > attributes and tests regions. I think the end idea would be that
> > drivers would use the normal
> > ioremap/change_page_attr/remap_page_range mechanisms like they
> > already do, and these mechanisms would in turn use cachemap to make
> > sure there's no conflicts. I'm completely open to how any specific
> > details should work, and any changes needed to be made.
> 
> Looks good for starting. The patch could use some minor cleanup still,
> but it should be good enough for testing.
> 
> As for an interface - i still think it would be cleaner to just
> call it from change_page_attr(). Then other users only need to
> call a single function. But that's easily changed.
> 
> To make it really useful I think we need ioremap_wrcomb() and support
> in the bus/pci mmap function (the PCI layer already has ioctls for this,
> they are just ignored on i386 right). Then the X server could
> start using it. 
> 
> Without any users the testing coverage would be probably not too good,
> but it needs some testing in the real world before it could 
> be merged first. Maybe it could be simply hooked into the AGP
> driver and into some DRM driver. Then people would start testing
> it at least.

This would also be extremely useful on machines with large amounts
of memory, for write-back mappings.  With large amounts but odd sized
entries it becomes extremely tricky to map all of the memory using
mtrrs.

Last I looked the common remedy was to using overlapping mtrrs
which the kernel does not understand and that make it impossible
for X to setup write-combining MTRRs.

The memory map on x86 shows no hope of getting simpler and mtrrs 
are getting continually less good at being able to scale so getting
PAT support of some kind in the kernel would be extremely good.

Eric

  parent reply	other threads:[~2004-04-15  4:11 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1KifY-uA-7@gated-at.bofh.it>
2004-04-13  0:01 ` PAT support Andi Kleen
2004-04-13 16:21   ` Terence Ripperda
2004-04-14  0:58     ` Andi Kleen
2004-04-16 18:07       ` Terence Ripperda
2004-04-17  0:42         ` Andi Kleen
2004-04-19 22:54           ` Terence Ripperda
2004-04-20 18:51             ` Andi Kleen
2004-04-21 23:19               ` Terence Ripperda
2004-04-22  4:21                 ` Andi Kleen
2004-04-15  4:11   ` Eric W. Biederman [this message]
2004-04-15 16:38     ` Andi Kleen
2004-04-15 18:39       ` Eric W. Biederman
2004-04-15 21:38 Albert Cahalan
  -- strict thread matches above, loose matches on Subject: below --
2004-04-13  5:34 Manfred Spraul
2004-04-13 14:02 ` Pavel Machek
2004-04-13 16:40 ` Terence Ripperda
2004-04-15  4:05 ` Eric W. Biederman
2004-04-12 22:29 Terence Ripperda
2004-04-13  8:36 ` Andy Whitcroft
2004-04-13 16:50   ` Terence Ripperda

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=m1fzb56fu2.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=ak@muc.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox