> Your patches just shove another extra into the existing code base
quoted text
> without doing any consolidation work and without any consideration of
> problems we need to urgently solve in this area.

I fixed the problems in CPA I was aware of -- I'm not aware of 
any other current ones (urgent or not). 

quoted text
> Your only care is to get stuff merged which is interesting for you. 

Very true -- by definition I'm not interested in things I'm not interested 
in. Thanks for reminding me of that :-) However it would surprise 
me if that was different for you or anybody else.

quoted text
> can understand that, but it should be entirely clear to you as an
> engineer that ignoring the existing problems and adding more (even

Can you elaborate on the existing problems in the CPA code? 
(excluding issues already fixed in my CPA patch series) 
I'm truly curious what these are.

quoted text
> PAT is high on the requirements list, not because it's not complex (it
> definitely is), but simply because Linux has a years long of backlog
> (it's the only modern OS on the planet still not using PAT) and
> hardware makers are stepping beyond the limits of MTRRs. There is an
> increasing number of systems which don't work under Linux properly due
> to the MTRR limitations, but work perfectly fine with other
> OSs. 

Actually I'm not aware of any shipping box that doesn't work currently on Linux
because of no PAT or MTRRs. Do you have an example? I know BIOS 
people have been grumbling about it, but I don't think there were
any real show stoppers so far.

It is pretty hard to imagine that ever being the case anyways. We already
did non caching mappings for quite some time using the page tables
(although admittedly not fully correct and a little unsafe, but probably 
well enough in practice). The only value add that you get from
true PAT support is write-combining and write combining over uncacheable
is always only an optimization; nothing required to make 
boxes work.

Admittedly it is helpful for 3d graphics, but the current state
is that the big out of tree 3d stuff reprograms the PAT registers
on its own. While replacing that with an in tree solution
will be a good idea it is not really all that urgent.

But I'm not saying that that PAT shouldn't be merged 
anyways -- i wouldn't have worked on these patches earlier
if that was the case -- i'm just disagreeing on you
saying it is more important than anything else. I also think
it will take longer to make it really stable enough to be mergeable 
(.26 target would be probably ambitious) so I don't think other patches 
should be delayed for such a long time just because of it.

quoted text
> While PAT is a 10 years old hardware feature, gbpages is a feature for
> a brand new chip, which is not even available to mere mortals in a
> useable form. And there is no real problem with not having gbpages for

AMD shipped over 400k of them last quarter and they are perfectly usable 
if you run them with an uptodate BIOS.

quoted text
> some time. So where is the pressure to get that in? 

For me it's mostly that I was sitting too long on that patch
(ok that's my own fault) so I finally want to get it out. 

Also I don't know of any real reason to delay it much longer -- it is 
not particularly tricky and contrary to your claims it does not actually 
interact in a great way with with PAT or anything else pretty much.
Ok there are some changes to CPA, but they're IMNSHO quite
straight forward extensions of already existing code in there.

quoted text
> Just because it
> can be done and happens to work on some test machine?

When a patch kit works and does not cause any big risks and is 
clean code and there are no fundamental design problems 
what use is there in delaying it unnecessarily? 

-Andi

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