Kernel 2.6.38 really impresses!

[VinzC]

Hi all.

I couldn't wait until 2.6.38 was available so I compiled it yesterday afternoon and tested it right away. I just had forgotten to recompile my ATI video driver but in the end it keeps its promises. I ran a -j16 make against glibc and gcc, ran a video through VLC and started a huge transfer through USB to my external disk. The video ran flawlessly without a hickup. I'm really pleased to see my desktop responsive again, almost like I never saw it (but I'd exaggerate ).

Honestly, taste it, try it use it! It's worth the change. Be sure to check CONFIG_CGROUPS and CONFIG_CGROUP_SCHED in your kernel config for it's not enabled by default. I guess Pappy Mc Fae will have a very good time preparing a new seed for this kernel .

Cheers.

[leifbk]

Be sure to check CONFIG_CGROUPS and CONFIG_CGROUP_SCHED in your kernel config for it's not enabled by default.

Cheers.

I'm running this kernel too, I've had gentoo-sources ~amd64 in my /etc/portage/package.keywords for some time, and 2.6.38 arrived yesterday, less than two days after it was announced by Linus. That's bleeding edge

I can't find any CONFIG_CGROUP_SCHED. Do you mean CONFIG_SCHED_AUTOGROUP ?

[jms.gentoo]

you only need to select
-> General setup
-->Automatic process group scheduling [CONFIG_SCHED_AUTOGROUP]
it will select automatically the rest
Selects: EVENTFD [=y] && CGROUPS [=y] && CGROUP_SCHED [=y] && FAIR_GROUP_SCHED [=y]

if you deselect CONFIG_SCHED_AUTOGROUP and go back to configure you will see these one
-> General setup
-->Control Group support[CONFIG_CGROUPS](CGROUPS )
--->Group CPU scheduler[CONFIG_CGROUP_SCHED](CGROUP_SCHED)
---->Group scheduling for SCHED_OTHER[FAIR_GROUP_SCHED]

Conclusion :to get the famous " 233-line pach " simply
select -> General setup
-->Automatic process group scheduling [CONFIG_SCHED_AUTOGROUP] (SCHED_AUTOGROUP)
and you're good to go

[cach0rr0]

i havent read up on this a ton - is this a CPU scheduling deal, IO scheduling, which?
mainly wondering if, come time to test out .38, I should pluck out BFS and go with this, or if this isn't a replacement, and is something else entirely

[bobspencer123]

Thanks for the update on this kernel. I will have to try it out. I wonder if this also fixes the fragmentation issue between nfs transfers and xfs?

[VoidMage]

See git log entry for details.

[Jaglover]

i havent read up on this a ton - is this a CPU scheduling deal, IO scheduling, which?
mainly wondering if, come time to test out .38, I should pluck out BFS and go with this, or if this isn't a replacement, and is something else entirely

This is about TTY-based group scheduling which is not TTY-based [any more].

https://lwn.net/Articles/418884/

[Ant P.]

Is this overhyped patch really so much better than the BFS I've been using for the past 18 months or so? I'm watching 720p video with a gcc -j32 compile on it right now.

[cach0rr0]

This is about TTY-based group scheduling which is not TTY-based [any more].

https://lwn.net/Articles/418884/

cheers for the link, interesting discussion they have going on.

having said that, I'm somewhat in Ant_P's same boat.
Sounds like heaps of hype, and while I *am* curious, things are working delightfully for me with BFS, I would be interested to see a compelling reason to make the change, rather, BFS is doing everything I need at the moment, and while I'm keen on squeezing out every last bit I can from this machine, if it's only a nominal gain, dunno, hard sell. I *am* glad mainline is starting to pay a bit more attention to interactivity requirements from desktop users, though, instead of just seeing if we can work efficiently with 4096 cores.

[wswartzendruber]

Wonder how long it'll take it to show up in hardened-sources.

[printf]

usually how long it takes for at least gentoo-sources be unmasked with this kernel?

[Anon-E-moose]

Add me to the BFS has been giving me good performance camp, though I may try 2.6.38 sometime, I'll wait for further testing.

[VinzC]

Is this overhyped patch really so much better than the BFS I've been using for the past 18 months or so? I'm watching 720p video with a gcc -j32 compile on it right now.

I wouldn't say overhyped . IT deserved all the... «noise» there have been around. The tests I made allowed me to use my laptop as if it weren't stressed at all. Before I would have had to wait (especially with -j16) until compile was over. That's also why I had to decrease the -j value to 3 because compiling certain packages made my computer (Core2 Duo) totally unresponsive for seconds.

Those times are over!

[pilla]

Yes, it impressed me too. Xorg can't stop crashing on it

[Gusar]

Err, what's the point of using more than -j3 on a dual core machine?

[PaulBredbury]

Meh, BFS is tons better, with:

Code: Select all

alias mplayer="ionice -c2 nice -n -4 /usr/bin/mplayer"
alias make='ionice -c3 schedtool -D -e /usr/bin/make'

[Ant P.]

Err, what's the point of using more than -j3 on a dual core machine?

There is none, bar showing off. In fact -j3 itself is only needed because the vanilla scheduler has flaws; BFS on a dual core reaches peak efficiency at -j2.

[NathanZachary]

It seems that there is a problem with 2.6.38 though. udev won't build with it:

It seems that the problem is with videodev.h being removed from 2.6.38:

http://comments.gmane.org/gmane.linux.h ... evel/16670

The error I get on my new installation is:

Code: Select all

extras/v4l_id/v4l_id.c:31:28: error: linux/videodev.h: No such file or directory

There are other errors, but it fails to build (with or without the 'extra' USE flag).

Anyone have suggestions?

[d2_racing]

I use this configuration :

Code: Select all

General stuff
[*] Control Group support
     [ ]   Example debug cgroup subsystem
     [*]   Namespace cgroup subsystem                                                                               
     [*]   Freezer cgroup subsystem                                                                            
     [*]   Device controller for cgroups                                                                          
     [*]   Cpuset support                                                                                          
     [*]     Include legacy /proc/<pid>/cpuset file                                                               
     [ ]   Simple CPU accounting cgroup subsystem                                                                
     [ ]   Resource counters                                                                                     
     -*-   Group CPU scheduler  --->                                                                          
    <*>   Block IO controller                                                                            
          [ ]     Enable Block IO controller debugging 
[*] Automatic process group scheduling

[graysky]

Meh, BFS is tons better, with:

Code: Select all

alias mplayer="ionice -c2 nice -n -4 /usr/bin/mplayer"
alias make='ionice -c3 schedtool -D -e /usr/bin/make'

+1 for this. It'll be interesting to see how Con implements the 2.6.38-ready BFS with this code.

http://ck-hack.blogspot.com/2011/03/263 ... eases.html

[VinzC]

Err, what's the point of using more than -j3 on a dual core machine?

There are plenty of such questions with GNU/Linux! And the answer would always be: «because I can!»

It seems that there is a problem with 2.6.38 though. udev won't build with it:

It seems that the problem is with videodev.h being removed from 2.6.38:[...]

Anyone have suggestions?

I have udev-162 and it compiles fine. What version do you have?

Meh, BFS is tons better, with:

Code: Select all

alias mplayer="ionice -c2 nice -n -4 /usr/bin/mplayer"
alias make='ionice -c3 schedtool -D -e /usr/bin/make'

The difference is 2.6.38 will automatically assign time slices without any overhead. I also used to renice (not the way you've shown, which I didn't know) but I found it boring in the end . Say 2.6.38 and AUTO_CGROUPS are for the lazy then .

[Gusar]

There are plenty of such questions with GNU/Linux! And the answer would always be: «because I can!»

Which is a valid answer as such. But still, -j16 on a dual-core has no real value, it's ridiculous. And if this "miracle" patch only does something at a ridiculous setting, it's equally valid to question the "miracleness" (yes, that's a word! ) of it.

[graysky]

There are plenty of such questions with GNU/Linux! And the answer would always be: «because I can!»

Which is a valid answer as such. But still, -j16 on a dual-core has no real value, it's ridiculous. And if this "miracle" patch only does something at a ridiculous setting, it's equally valid to question the "miracleness" (yes, that's a word! ) of it.

This is what Con argued. Why optimize a kernel to perform at insane workloads when 99.99 % of the user don't use their machines as such.

[jcTux]

It seems that there is a problem with 2.6.38 though. udev won't build with it:

It seems that the problem is with videodev.h being removed from 2.6.38:

http://comments.gmane.org/gmane.linux.h ... evel/16670

The error I get on my new installation is:

Code: Select all

extras/v4l_id/v4l_id.c:31:28: error: linux/videodev.h: No such file or directory

There are other errors, but it fails to build (with or without the 'extra' USE flag).

Anyone have suggestions?

Udev compiles fine here

Code: Select all

USE="extras -devfs-compat -old-hd-rules (-selinux) -test"

Code: Select all

uname -r
2.6.38-gentoo

[VinzC]

There are plenty of such questions with GNU/Linux! And the answer would always be: «because I can!»

Which is a valid answer as such. But still, -j16 on a dual-core has no real value, it's ridiculous. And if this "miracle" patch only does something at a ridiculous setting, it's equally valid to question the "miracleness" (yes, that's a word! ) of it.

This is what Con argued. Why optimize a kernel to perform at insane workloads when 99.99 % of the user don't use their machines as such.

Well, I really don't like percentages like this (i.e. what's this estimation based on?) but I agree with you: most GNU/Linux users won't probably load their system that much hence the impact of the patch is limited. But the main advantage is there's no longer a need to manually tweak performance using a command. It's handled automatically, which clueless users will probably appreciate.

OTOH -j16 was indeed for the sake of testing. Of course it makes no sense to raise that number that much. [I've compiled hugin and then I saw the effect: computer not responsive for a while, high latency, high I/O rate and much longer waits.] But instead of restoring -j3, I'll keep -j5 for a while and see.

Finally, even if this patch might happen to prove useless for a majority of users, it doubtlessly comes handy with Gentoo just because compiling is a common task. No need to renice, just compile as much as you want and watch. That's the point.