Nick's scheduler v19a

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/

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.

Quoted 9 lines · Markus Hästbacka

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

Quoted 25 lines · Nick Piggin

Quoted 10 lines · Markus Hästbacka

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

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

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

Quoted 8 lines · Nick Piggin

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

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

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.

That may be true, but why should I complain anymore? Nick made a really great patch that makes things working for me.

Quoted 3 lines · Markus Hästbacka

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

Quoted 14 lines · Timothy Miller

Quoted 3 lines · Markus Hästbacka

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.

Hi Nick,
I noticed that v19a patch wont apply to 2.6.0-test11-bk1

Quoted 3 lines · Markus Hästbacka

Hi Nick,
I noticed that v19a patch wont apply to 2.6.0-test11-bk1

Hi Markus,
OK, thanks for the notice, I'll bring it up to date when I get time

Hi again Nick, I ported the patch forward to -bk1>, the problem was here:
<snip>
- if (sync)
<snip>

That should be:
<snip>
- if (sync && (task_cpu(p) == smp_processor_id()))
<snip>
when patchin kernel/sched.c
Is this right?

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.