On Tue, Jan 22, 2008 at 03:06:00PM +0100, Thomas Gleixner wrote: > On Tue, 22 Jan 2008, Andi Kleen wrote: > > > > First priority is getting CPA and PAT consolidated before we put new > > > > PAT seems to be still quite unstable and frankly for me it is > > unclear how long it will take to it become stable. It would > > not surprise me if it takes longer than the .26 merge window. > > Definitely, if we change the code further without doing anything to > consolidate it in the first place. > > Have you even cared to look, why PAT is so ugly and fragile ? Simply
Well I was second generation hacker on the patchkit (after Eric B.) and wrote quite some code in it, so yes I'm a little familiar with how it works... > because it interferes/interacts with CPA and the page table code. So No that is not its main problem I believe. Main problem are all the driver and other subsystem interactions (it is a little bit similar to power management where you have lots of little bits all over right instead of a single big one). The actual page table handling is the smallest issue and well understood anyways. gbpages on the other hand does not change the driver interaction problem at all. > adding further stuff to that area without considering the requirements > of PAT will make it worse. I don't think gbpages has much to do with how well PAT works or not. It is just a different way to map the large areas of the direct mapping that do not contain any mmio or aperture mappings. These areas are not affected by PAT. By definition (in Linux) if PAT is active for something there are no gbpages anymore. PAT essentially only works on areas which are already split into 4K and the gbpages code does not come into play on those at all. > > That seems to me like against your own principles -- simple stuff > > first -- that you two harped on so extensively on earlier this thread. > > Not at all. If the simple stuff makes it harder to do something else, I don't think that's the case here. > > If your patches are so simple, then they can be done on top of a > consolidated CPA/PAT easily. Sure they can -- i did that in fact with PAT only -- my worry is just that there is no time frame when someone will actually produce working PAT and then consolidated CPA. So basically my relatively simple (and imho not very intrusive) feature is queued behind two very complicated projects with unclear time frame and might be delayed forever for those. And the rationales I so far heard for this particular prioritization were not very convincing to say the least. Frankly I suspect Ingo hadn't actually looked at the gbpage code really before coming up with it and from your comments it doesn't sound like you did either. > > But now that it is gone again anyways delaying the gbpages for it again > > would be quite unfortunate from my perspective. > > I can understand that, because it is in the way of your particular > interests, but we have to look at the global picture and not at the > personal preferences of you or anyone else. According to you and Ingo "the global perspective" is to get simple stuff first in. But in this case you're doing the complicated (and worse the unfinished) stuff first which seems to be against your own principles. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/