Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linux 2.5.2 Kernel Released

Posted by Hemos on from the go-and-compile dept.

valdis writes "Amazing.. it's been out over 3 hours and not discussed to death. Well, maybe there's not as many bleeding-edge crazies out there. But if there are, here's what's new. You can get it at the usual place, but please use the mirrors if you can."

3 of 234 comments (clear)

  1. Mirrors by Rentar · · Score: 5, Informative

    Apart from the entire 'slashdot is not freshmeat'-discussion I'd like to note, that maybe slashdot should not mention the URL to the kernel archive, but only the URL for the mirrors-list. I'm sure everyone able to compile and use a 2.5.x kernel is able to find the correct download directory, should he be confronted with a mirror list.

  2. Re:Cool by Kynde · · Score: 5, Informative

    Those of you anxious to contribute by testing I suggest you get acquainted with the following sites:
    Linux Kernel Mailing List FAQ (a must read before submitting bugs or oopses)
    Good site about kernel hacking (not just for newbies either)

    --
    1 Earth is warming, 2 It's us, 3 it's royally bad, 4 we need to take action NOW
  3. Re:O(1) Scheduler? by thing12 · · Score: 5, Informative
    I don't think it's in the kernel, but you can get the 'final' patch here (there's one avaiable for the 2.4 series as well):

    http://people.redhat.com/mingo/O(1)-scheduler/

    I must say that after using it for a few days, I'm impressed. It totally changes the characteristics of multiprocess servers like Apache and PostgreSQL under high load. For example, I've run ApacheBench against a mod_perl script that queries a pgsql database, in the new scheduler I get a mean response time that is N*1.05*concurrency with a standard deviation of less than 1% of the mean. In the old scheduler I'd get a mean that is N*1.07*concurrency with a sd of up to 75% of the mean. So in other words you get essentially the same throughput with both schedulers (O(1) appears slightly faster in my limited testing). But what's more important is that in the O(1) scheduler everyone is treated equally - they all get served in 1.05*N*concurrency, no more, no less -- while with the old scheduler some requests get a response that's 1*N and others get a response all the way up to 4*N*concurrency.

    IMHO, it's better to give everyone an equal level of service than to randomly favor one group of users over another.