Message-ID: <20080122142147.GD19936@wotan.suse.de>
Date:	Tue, 22 Jan 2008 15:21:47 +0100
From:	Andi Kleen <ak@...e.de>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Andi Kleen <ak@...e.de>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org, jbeulich@...ell.com,
	venkatesh.pallipadi@...el.com, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: CPA boot crash (was: [PATCH] [0/36] Great change_page_attr patch series v3)

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists