Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> that is (yet another) major misconception on your part. "Drivers" are an
> easy to blame target (i guess because there's no one out there to defend
> a vague "drivers" accusation), and they are not the problem here _at
> all_.
In this case the proble
> Your patches just shove another extra into the existing code base
> 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).
>
On Tue, 22 Jan 2008, Andi Kleen wrote:
> 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.
No, the global perspective is to ge
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > 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 lo
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 bec
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
> 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.
You're saying you want to delay an relati
On Mon, 21 Jan 2008, Andi Kleen wrote:
> > It's a first shot so it might not yet be perfect - although so far it
> > looks good in testing on 4-5 testsystems here, on mixed 64-bit and
> > 32-bit boxes. Doing it this way was a pretty straightforward process, it
> > took less than an hour - and th
> It's a first shot so it might not yet be perfect - although so far it
> looks good in testing on 4-5 testsystems here, on mixed 64-bit and
> 32-bit boxes. Doing it this way was a pretty straightforward process, it
> took less than an hour - and the end result feels much better in terms
> of
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > i pointed it out how to port a larger series ontop of a whitespace
> > cleanup patch:
> >
> > http://lkml.org/lkml/2008/1/18/281
> >
> > the "there's an easy technique" bit.
>
> But it will be even easier to just redo the cleanup stuff at the end.
> i pointed it out how to port a larger series ontop of a whitespace
> cleanup patch:
>
> http://lkml.org/lkml/2008/1/18/281
>
> the "there's an easy technique" bit.
But it will be even easier to just redo the cleanup stuff at the
end. If I do what you describe here I'm sure I will make a mis
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> That rule of thumb makes sense if someone does a series from scratch,
> but redoing a large existing series just because someone else sneaked
> in a white space patch at the wrong time does not seem to be very
> efficient to me.
i pointed it out how t
On Friday 18 January 2008 17:21:18 Ingo Molnar wrote:
>
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > > > (except for the white space changes, but that can be redone once
> > > > everything settled down again). Then it will be bisectable.
> > >
> > > it's a revert barrier (within v2.6.25),
>
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > > (except for the white space changes, but that can be redone once
> > > everything settled down again). Then it will be bisectable.
> >
> > it's a revert barrier (within v2.6.25),
>
> What is a revert barrier?
>
> Anyways of course the way to handle
On Friday 18 January 2008 17:07:57 Ingo Molnar wrote:
>
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > > could you please make your queue bisectable?
> >
> > The idea was that you git revert the original patches I referenced and
> > then drop the undo patches since I reimplement all that in di
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > could you please make your queue bisectable?
>
> The idea was that you git revert the original patches I referenced and
> then drop the undo patches since I reimplement all that in different
> ways (except for the white space changes, but that can be
On Friday 18 January 2008 17:01:04 Andi Kleen wrote:
>
> > could you please make your queue bisectable?
>
> The idea was that you git revert the original patches
Or rather instead of git reverting drop them completely. I'm sure it can
be done somehow. You should also move
CPA: Implement chan
> could you please make your queue bisectable?
The idea was that you git revert the original patches I referenced
and then drop the undo patches since I reimplement all that in different ways
(except for the white space changes, but that can be redone once everything
settled down again). Then it
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> hm, i just found a failing 64-bit .config while testing your CPA
> patchset:
>
> [1.916541] CPA mapping 4k 0 large 2048 gb 0 x 0[0-0] miss 0
> [1.919874] Unable to handle kernel paging request at 0335aea8
> RIP:
> [1.919874] []
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> hm, i just found a failing 64-bit .config while testing your CPA
> patchset:
>
> [1.916541] CPA mapping 4k 0 large 2048 gb 0 x 0[0-0] miss 0
> [1.919874] Unable to handle kernel paging request at 0335aea8
> RIP:
> [1.919874] []
20 matches
Mail list logo