Re: [RFC] Cachemap for 2.6.12rc4-mm1. Was Re: [PATCH] enhance x86 MTRR handling

[Andi Kleen]

On Wed, May 18, 2005 at 05:15:40PM -0500, Terence Ripperda wrote:
> On Thu, May 19, 2005 at 12:03:56AM +0200, ak@xxxxxxx wrote:
> > > right now I think there were a lot of excessive printouts for
> > > debugging purposes. I also have no doubts that there are coding style
> > > differences that need to be cleaned up (feel free to tell me when my code
> > > sucks or isn't up to style).
> > 
> > Perhaps should concentrate on the basic design first.
> 
> sure, feel free to tell me if that sucks as well :)

The main thing I am not sure about in the basic design was
the overlapping handling. I suspect that needs to be discussed
again, perhaps even with input from some CPU vendor people.

My feeling is that overlapping is not good and should be avoided.

Then we need a user interface for the X server too, which
also needs to be designed. /proc/bus/pci/*/* has some ioctls
for this on other platforms that might be adapted (common
interface would be best of course), but I am
not sure the code is powerful enough for everything PAT offers.
Probably needs some enhancements (do we really want to support
the obscure PAT settings like write protect though?)

Do we need to handle the fixed range legacy MTRRs too?

It would be better to move the "range list using rbtree" code somewhere
into lib. It certainly seems to be needed often (I did my own
version for the NUMA policies ;-) and it doesn't make
much sense to duplicate all the time. iirc there is at least another
patch pending with a similar datastructure. 

I suppose you saw the list I sent to Dave. These are the things
that came to mind while reading it. I haven't gone over everything
in detail though.

I hope to have some time soon to go over all of this more closely.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/