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
> 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).
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).
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 problem is that
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
* 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
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
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
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
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 the end
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
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
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
* 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 lots of
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 get a
> 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.
* 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.
If I do what
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
> 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
* 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
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
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
* 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
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
> 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
* 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]
* 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 to
* 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]
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),
What is a
* 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 that is the
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 different
* 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 redone
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
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
* 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]
39 matches
Mail list logo
