[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.1.00.0801221439520.3199@apollo.tec.linutronix.de>
Date: Tue, 22 Jan 2008 15:06:00 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Andi Kleen <ak@...e.de>
cc: 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, 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
because it interferes/interacts with CPA and the page table code. So
adding further stuff to that area without considering the requirements
of PAT will make it worse.
> You're saying you want to delay an relatively simple and imho
> relatively mature feature like gbpages after that complicated and risky
> feature PAT? Please take a look at the patches; they're really
> not very complicated.
It's not a question of complicated or not. Fact is, that PAT is
interfering with all this and any new feature will make it harder to
stabilize.
> 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,
then it is not longer simple. Then it is simply in the way.
If your patches are so simple, then they can be done on top of a
consolidated CPA/PAT easily.
> For me it would make much more sense to put the gbpages first
> than to delay them for PAT. I only didn't argue this strongly
> earlier because PAT was already rushed in (for me quite suprisingly)
> and I didn't want to argue for dropping it.
>
> 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.
Thanks,
tglx
--
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