

Forget 200 lines, Red Hat speeds up Linux with 4 lines of code - signa11
http://blog.internetnews.com/skerner/2010/11/forget-200-lines-red-hat-speed.html

======
naner
Pottering's code appears to just be a proof of concept. It really doesn't make
sense to have this behavior in a bash initialization file. Not to mention
you'd have to launch your X session from that bash instance (and you'd have to
be using a bash-compatible shell to begin with or port the code your preferred
shell) to get the desired effect.

That is nice, but I'd rather see how this would be properly implemented in
userspace. Pottering was eager to prove the performance increase could be
applied to userspace, not how he would integrate this approach with current
Linux desktops.

Also, as Linus noted, it would be nice for users to just perform a standard
system update and all of the sudden have a more responsive desktop on reboot.
If it can be done in userspace, distros should flesh out the userspace code
and disable the kernel feature. Once it is reasonably handled in userspace
across Linux distributions it can be removed from the kernel.

------
DanI-S
Is anyone else consistently astonished by how rude and offensive the leaders
of FOSS projects can be to legitimate contributors?

~~~
ominous_prime
I find more often than not, that "abrupt and to-the-point" is mistaken for
"rude and offensive". A FOSS community is a meritocracy, and there's a lot of
people who stroll in with a lot of talk, nothing to back it up. The few that
show up with code and/or data are often received very well.

People with the aptitude to become community or project leaders often like a
good debate (OK, sometimes it seems like an argument), and will often provoke
it, if only to see how well the point can be defended. When the chips are down
though, rational decisions based on facts is what wins.

I may not be as gruff as some of the more infamous names around, but I will
often argue a point, as well as play devil's advocate, just to see how the
debate plays out. I learn a lot that way, whether I'm correct or not.

[Edit] Re:Linus I agree that Linus' reply was a rude, and perhaps I've been
desensitized to this over time, and let it slide too often. My comment
however, was meant for the more general case to which I replied.

~~~
jamesaguilar
> I find more often than not, that "abrupt and to-the-point" is mistaken for
> "rude and offensive".

Calling someone's theory bullshit is rude and offensive. Telling someone they
are full of shit is also. Abrupt and to the point as a general class of
communication further is often rude. Making or attempting to make people feel
worse than you need to to get your point across efficiently is offensive.

In this case, for example, Linus could have simply said, "That's a nice
theory. If you can prove it, we'll consider it." That's more to-the-point,
communicates the entirety of what Linus managed to in his email, and also is
not rude.

~~~
eldenbishop
I disagree. There are hundreds if not thousands of people willing to waste his
time (Linus) with theory and conversation, his abrupt, rude tone makes it
clear that unless you are communicating actual information, not just theories,
don't bother him with this stuff. It is rude but I expect he does not want to
be bothered with fluff, only real information.

------
qjz
I keep my .bashrc in version control and install it on all systems where I use
bash. It's not the best place for platform-specific optimizations. Those 4
lines of code aren't portable, and there isn't a single line in my .bashrc
that requires root privileges. I realize the example was a proof-of-concept,
but I doubt this issue is easy to solve in userland, compared to just
automating it in the kernel.

~~~
gwern
So toss in an `if` to check whether the /sys/ directories exist!

------
mfukar
Alternate title: Red Hat speeds up _Red Hat Linux_ with 4 lines of code _and
systemd_.

I was wondering when the freedesktop dudes were going to make a "come back".
Linus, in fact, does not oppose the user level approach [1]. I too, however,
share his disgust for user level code to interact with every process and
group, it's just awful. The kernel seems like a good place to implement an
interface for this, that user space can use effectively and without imposing
extra complexity on the kernel.

[1] [http://marc.info/?l=linux-
kernel&m=129018914723592&w...](http://marc.info/?l=linux-
kernel&m=129018914723592&w=2)

~~~
wynand
[http://www.webupd8.org/2010/11/alternative-to-200-lines-
kern...](http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-
patch.html) is also about this story and how to set up this scheme in Ubuntu
and one commenter mentioned that he used a similar approach in Suse.

~~~
vimalg2
This actually worked for me on a recent quad-core amd with Ubuntu 10.04. My
sunspider bench scores on Google chrome 8.x shot up by 30%, IIRC. This was a
couple of weeks ago.

It seemed like the CPU graph seemed to show higher cpu utilization line-trace
for the core that was running the benchmarking Chrome process.

That's my layman observation after the patch.

------
palish
Whether it's 200 lines or 2,000 lines, what's with the fascination of "X
lines"?

~~~
enanoretozon
It causes readers to either slap their foreheads and say 'oh wow, 200 lines? I
could have done that! why didn't I think of it?' or 'oh wow, it takes true
genius to hit _just_ the right 200 lines. I could have never done that!', the
common factor being 'oh wow'

~~~
palish
Why is the "I could have done that" reaction a good thing?

That implies "this should have been done from the beginning, but the
developers were lazy / incompetent"

Also, it is better to have 500 lines of well-commented code with informative
variable names, than _just_ the right 200 lines. Software development should
not be reserved for voodoo witch doctors who know _just_ the right mysterious
incantation to produce the desired effect.

Encouraging people to have the mentality "do it in < N lines or don't try"
seems silly.

------
marbu
why not to link to lwn.net (<http://lwn.net/Articles/414817/>) instead?

~~~
gvb
Note to the puzzled: skip down to "TTY-based group scheduling" - this explains
_what_ the {200|4} line patches are doing.

~~~
vimalg2
Thanks, I understand somewhat after i read this.

------
apetresc
Out of curiosity, has the original kernel patch been merged into mainline yet?
Which version will it be launching in?

