http://www.kerneltrap.org/~npiggin/v19a/
So the previous didn't exactly improve interactivity.
This one seems to be better. Major thing is microsecond timeslice
accounting. Other small fixes related to the microsecond stuff.
No idea what this has done to context switch and wake up performance,
but it should be able to be improved a bit.
I've made patches for Linus and Andrew's trees.
Hi nick! here's some feedback.
This one day last week, I thougt I could test your scheduler patch.
I noticed something really good with it. My X had really fast startup.
everything worked really fast. Even games worked much better than any in
kernel before (I've tested all from 2.5.74).
So I hope you'll port this patch for test10> if this one wont patch
clearly.
Thanks.
On Sat, 2003-11-15 at 15:11, Nick Piggin wrote:
> http://www.kerneltrap.org/~npiggin/v19a/
>
> So the previous didn't exactly improve interactivity.
>
> This one seems to be better. Major thing is microsecond timeslice
> accounting. Other small fixes related to the microsecond stuff.
> No idea what this has done to context switch and wake up performance,
> but it should be able to be improved a bit.
>
> I've made patches for Linus and Andrew's trees.
>
> -
> 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/
--
"Software is like sex, it's better when it's free."
Markus H?stbacka <midian at ihme.org>
Markus H?stbacka wrote:
>Hi nick! here's some feedback.
>This one day last week, I thougt I could test your scheduler patch.
>I noticed something really good with it. My X had really fast startup.
>everything worked really fast. Even games worked much better than any in
>kernel before (I've tested all from 2.5.74).
>
>So I hope you'll port this patch for test10> if this one wont patch
>clearly.
>
Hi Markus,
Thanks for testing. That sounds quite remarkable, is it possible that
some other change has made the difference? What kernel version did
you patch against, and did you try that same kernel and .config without
my patch? Anyway, I'm glad you're having good results.
Yes, this one will probably apply to test10 should it ever apper. If not
I will port it.
Nick
Hi nick.
it seems that this patch changed everything, I patched against
2.6.0-test9-bk19. I didn't upgrade any software before I booted to your
patch. and I tested the 2.6.0-test9-bk22 without the patch it worked
just as all other kernels without the patch. I've had the same .config
from test3 (maybe some small changes if new drivers appeared).
I can't say that 2.6 performance is bad, it's better than 2.4, but now
this is even better.
So now I'm booted back to your patch and I like this difference in X
performance, I can't ask for more. :)
Regards,
Markus
On Fri, 2003-11-21 at 01:34, Nick Piggin wrote:
> Markus H?stbacka wrote:
>
> >Hi nick! here's some feedback.
> >This one day last week, I thougt I could test your scheduler patch.
> >I noticed something really good with it. My X had really fast startup.
> >everything worked really fast. Even games worked much better than any in
> >kernel before (I've tested all from 2.5.74).
> >
> >So I hope you'll port this patch for test10> if this one wont patch
> >clearly.
> >
>
> Hi Markus,
> Thanks for testing. That sounds quite remarkable, is it possible that
> some other change has made the difference? What kernel version did
> you patch against, and did you try that same kernel and .config without
> my patch? Anyway, I'm glad you're having good results.
>
> Yes, this one will probably apply to test10 should it ever apper. If not
> I will port it.
>
> Nick
--
"Software is like sex, it's better when it's free."
Markus H?stbacka <midian at ihme.org>
Markus H?stbacka wrote:
>Hi nick.
>it seems that this patch changed everything, I patched against
>2.6.0-test9-bk19. I didn't upgrade any software before I booted to your
>patch. and I tested the 2.6.0-test9-bk22 without the patch it worked
>just as all other kernels without the patch. I've had the same .config
>from test3 (maybe some small changes if new drivers appeared).
>
>I can't say that 2.6 performance is bad, it's better than 2.4, but now
>this is even better.
>
>So now I'm booted back to your patch and I like this difference in X
>performance, I can't ask for more. :)
>
Well that's very good to hear :) err, just remember if you have
any specific problems with unpatched 2.6 to make a report. We
want the standard scheduler to run well too.
Thanks,
Nick
>
>Regards,
>
>Markus
>On Fri, 2003-11-21 at 01:34, Nick Piggin wrote:
>
>>Markus H?stbacka wrote:
>>
>>
>>>Hi nick! here's some feedback.
>>>This one day last week, I thougt I could test your scheduler patch.
>>>I noticed something really good with it. My X had really fast startup.
>>>everything worked really fast. Even games worked much better than any in
>>>kernel before (I've tested all from 2.5.74).
>>>
>>>So I hope you'll port this patch for test10> if this one wont patch
>>>clearly.
>>>
>>>
>>Hi Markus,
>>Thanks for testing. That sounds quite remarkable, is it possible that
>>some other change has made the difference? What kernel version did
>>you patch against, and did you try that same kernel and .config without
>>my patch? Anyway, I'm glad you're having good results.
>>
>>Yes, this one will probably apply to test10 should it ever apper. If not
>>I will port it.
>>
>>Nick
>>
>>
Hi again.
I'm not sure if this is because of the patch or what, but my X crashes
normally in ~2 days, and the framebuffer gets all messy (green lines,
can't see what I'm typing, etc.), this doesn't happen with your patch at
all, only with vanilla kernel(s). Maybe my hardware likes your patch or
something. My X have been running for four days now without any kind of
problem on the patched kernel. (I'm not sure if it's the kernel or what,
but reported it anyway). That's the only problem I've been getting more
than often.
There's no other problems, only that the kernel standard scheduler is a
bit slower than yours.
Regards,
Markus
On Fri, 2003-11-21 at 08:20, Nick Piggin wrote:
> Well that's very good to hear :) err, just remember if you have
> any specific problems with unpatched 2.6 to make a report. We
> want the standard scheduler to run well too.
>
> Thanks,
> Nick
--
"Software is like sex, it's better when it's free."
Markus H?stbacka <midian at ihme.org>
Markus H?stbacka wrote:
>Hi again.
>I'm not sure if this is because of the patch or what, but my X crashes
>normally in ~2 days, and the framebuffer gets all messy (green lines,
>can't see what I'm typing, etc.), this doesn't happen with your patch at
>all, only with vanilla kernel(s). Maybe my hardware likes your patch or
>something. My X have been running for four days now without any kind of
>problem on the patched kernel. (I'm not sure if it's the kernel or what,
>but reported it anyway). That's the only problem I've been getting more
>than often.
>
>There's no other problems, only that the kernel standard scheduler is a
>bit slower than yours.
>
>
Well yes its possible that my scheduler is better at hiding some bug. It
wouldn't be fixing anything, of course. It definitely was better at
exposing a kernel or postgresql bug when running OSDL's PostgreSQL tests -
I saw the crash 3 times I think, though never with standard kernel.
I don't know how you should be reporting X crashes. I guess you could report
the bug to the XFree86 guys as per their guidelines if you can reproduce the
crashes with an up to date 2.4 kernel.
Nick
>Regards,
>Markus
>
>On Fri, 2003-11-21 at 08:20, Nick Piggin wrote:
>
>
>>Well that's very good to hear :) err, just remember if you have
>>any specific problems with unpatched 2.6 to make a report. We
>>want the standard scheduler to run well too.
>>
>>Thanks,
>>Nick
>>
>>
but I wonder why the frambuffer gets messy too, I've heard that it's
pretty normal that X crashes sometimes under high load, but this of
course don't happen with your patch, I'm using debian sid, and of
course, I like to live on the edge.
And I don't see why I should report this, while it works now.
Regards,
Markus
On Fri, 2003-11-21 at 11:14, Nick Piggin wrote:
> Well yes its possible that my scheduler is better at hiding some bug. It
> wouldn't be fixing anything, of course. It definitely was better at
> exposing a kernel or postgresql bug when running OSDL's PostgreSQL tests -
> I saw the crash 3 times I think, though never with standard kernel.
>
> I don't know how you should be reporting X crashes. I guess you could report
> the bug to the XFree86 guys as per their guidelines if you can reproduce the
> crashes with an up to date 2.4 kernel.
>
> Nick
--
"Software is like sex, it's better when it's free."
Markus H?stbacka <midian at ihme.org>
Markus H?stbacka <[email protected]> writes:
> but I wonder why the frambuffer gets messy too, I've heard that it's
> pretty normal that X crashes sometimes under high load, but this of
That's not normal. X should never crash, whatever the machine is up
to.
--
M?ns Rullg?rd
[email protected]
That may be true, but why should I complain anymore? Nick made a really
great patch that makes things working for me.
Regards,
Markus
On Fri, 2003-11-21 at 11:54, M?ns Rullg?rd wrote:
> That's not normal. X should never crash, whatever the machine is up
> to.
--
"Software is like sex, it's better when it's free."
Markus H?stbacka <midian at ihme.org>
Markus H?stbacka wrote:
> That may be true, but why should I complain anymore? Nick made a really
> great patch that makes things working for me.
>
Are you interested only in the performance of your own computer, or do
you have any interest in the performance of other people's computers as
well?
If there's a bug, there's a bug, and you've identified it. Contrary to
the attitude of our friends in Redmond, the open source community tends
to see bugs as being really evil. If you've found a bug, we want to
investigate it and fix it.
Yes, but how could I know if the bug is in XFree86? in kernel? in the
nvidia driver module? and no, I can't even hope to try to reproduce bugs
without nvidia module, because no X => no bugs. If you tell me what I
need to add to kernel configuration to get some info while something
happens, I'll probably try to reproduce bugs when test10 is out with
vanilla kernel.
And yes, I'm intrested in the performance of other's computers too, but
if this is new then it's new, and I can't by my self know where the bug
(maybe) is.
Regards,
Markus
On Fri, 2003-11-21 at 18:19, Timothy Miller wrote:
> Markus H?stbacka wrote:
> > That may be true, but why should I complain anymore? Nick made a really
> > great patch that makes things working for me.
> >
>
>
> Are you interested only in the performance of your own computer, or do
> you have any interest in the performance of other people's computers as
> well?
>
> If there's a bug, there's a bug, and you've identified it. Contrary to
> the attitude of our friends in Redmond, the open source community tends
> to see bugs as being really evil. If you've found a bug, we want to
> investigate it and fix it.
--
"Software is like sex, it's better when it's free."
Markus H?stbacka <midian at ihme.org>
Well, you could try using XFree86's supplied "nv" driver to test without
the binary nvidia module.
Timothy's point is valid IMO - your help in identifying the bug will
help someone else down the road.
Peter C. Ndikuwera
Digital Solutions Ltd, Uganda
On Fri, 2003-11-21 at 20:00, Markus H?stbacka wrote:
> Yes, but how could I know if the bug is in XFree86? in kernel? in the
> nvidia driver module? and no, I can't even hope to try to reproduce bugs
> without nvidia module, because no X => no bugs. If you tell me what I
> need to add to kernel configuration to get some info while something
> happens, I'll probably try to reproduce bugs when test10 is out with
> vanilla kernel.
>
> And yes, I'm intrested in the performance of other's computers too, but
> if this is new then it's new, and I can't by my self know where the bug
> (maybe) is.
>
> Regards,
> Markus
>
> On Fri, 2003-11-21 at 18:19, Timothy Miller wrote:
> > Markus H?stbacka wrote:
> > > That may be true, but why should I complain anymore? Nick made a really
> > > great patch that makes things working for me.
> > >
> >
> >
> > Are you interested only in the performance of your own computer, or do
> > you have any interest in the performance of other people's computers as
> > well?
> >
> > If there's a bug, there's a bug, and you've identified it. Contrary to
> > the attitude of our friends in Redmond, the open source community tends
> > to see bugs as being really evil. If you've found a bug, we want to
> > investigate it and fix it.
On Fri, 2003-11-21 at 18:19, Timothy Miller wrote:
> Are you interested only in the performance of your own computer, or do
> you have any interest in the performance of other people's computers as
> well?
>
> If there's a bug, there's a bug, and you've identified it. Contrary to
> the attitude of our friends in Redmond, the open source community tends
> to see bugs as being really evil. If you've found a bug, we want to
> investigate it and fix it.
FYI:
Badness in pci_find_subsys at drivers/pci/search.c:132
Call Trace:
[<c024ef38>] pci_find_subsys+0xe8/0xf0
[<c024ef6f>] pci_find_device+0x2f/0x40
[<c024ee28>] pci_find_slot+0x28/0x50
[<f9e21099>] os_pci_init_handle+0x39/0x70 [nvidia]
[<f9cb586f>] _nv001243rm+0x1f/0x24 [nvidia]
[<f9dfc095>] _nv000816rm+0x2f5/0x384 [nvidia]
[<f9d648ac>] _nv003801rm+0xd8/0x100 [nvidia]
[<f9dfbbcf>] _nv000809rm+0x2f/0x34 [nvidia]
[<f9d656d0>] _nv003816rm+0xf0/0x104 [nvidia]
[<f9d63f8e>] _nv003795rm+0x6ea/0xaec [nvidia]
[<f9cce277>] _nv004046rm+0x3a3/0x3b0 [nvidia]
[<f9dcfb27>] _nv001476rm+0x277/0x45c [nvidia]
[<f9cb83aa>] _nv000896rm+0x4a/0x64 [nvidia]
[<f9cb9bc4>] rm_isr_bh+0xc/0x10 [nvidia]
[<c0123df6>] tasklet_action+0x46/0x70
[<c0123c10>] do_softirq+0x90/0xa0
[<c010d22d>] do_IRQ+0xfd/0x130
[<c010b574>] common_interrupt+0x18/0x20
Badness in pci_find_subsys at drivers/pci/search.c:132
Call Trace:
[<c024ef38>] pci_find_subsys+0xe8/0xf0
[<c024ef6f>] pci_find_device+0x2f/0x40
[<c024ee28>] pci_find_slot+0x28/0x50
[<f9e21099>] os_pci_init_handle+0x39/0x70 [nvidia]
[<f9cb586f>] _nv001243rm+0x1f/0x24 [nvidia]
[<f9d669dd>] _nv003797rm+0xa9/0x128 [nvidia]
[<f9dd3421>] _nv001490rm+0x55/0xe4 [nvidia]
[<f9dfc0d4>] _nv000816rm+0x334/0x384 [nvidia]
[<f9d648ac>] _nv003801rm+0xd8/0x100 [nvidia]
[<f9dfbbcf>] _nv000809rm+0x2f/0x34 [nvidia]
[<f9d656d0>] _nv003816rm+0xf0/0x104 [nvidia]
[<f9d63f8e>] _nv003795rm+0x6ea/0xaec [nvidia]
[<f9cce277>] _nv004046rm+0x3a3/0x3b0 [nvidia]
[<f9dcfb27>] _nv001476rm+0x277/0x45c [nvidia]
[<f9cb83aa>] _nv000896rm+0x4a/0x64 [nvidia]
[<f9cb9bc4>] rm_isr_bh+0xc/0x10 [nvidia]
[<c0123df6>] tasklet_action+0x46/0x70
[<c0123c10>] do_softirq+0x90/0xa0
[<c010d22d>] do_IRQ+0xfd/0x130
[<c010b574>] common_interrupt+0x18/0x20
As I said, it is nvidia.
(Sorry for the long respond time but I got somekind of debug information
just now...)
--
"Software is like sex, it's better when it's free."
Markus H?stbacka <midian at ihme dot org>