Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
X Software GUI Linux

Significant Interactivity Boost in Linux Kernel 673

An anonymous reader writes "The Linux kernel team is at it again. Linux creator Linus Torvalds recently proposed a patch to offer interactive processes a boost, greatly benefiting the X desktop, as well as music and movie players. O(1) scheduler author Ingo Molnar merged Linus' patch into his own interactivity efforts, the end result nothing short of amazing... The upcoming 2.6 kernel is looking to be a desktop user's dream come true."
This discussion has been archived. No new comments can be posted.

Significant Interactivity Boost in Linux Kernel

Comments Filter:
  • Amazing! (Score:5, Funny)

    by Anonymous Coward on Saturday March 08, 2003 @01:10PM (#5467402)
    Absolute astounding. I am in complete and utter shock over this. Truly, truly the most amazing thing I've ever seen or heard.

    Now what the hell is this article about?
    • Re:Amazing! (Score:4, Funny)

      by Anonymous Coward on Saturday March 08, 2003 @01:39PM (#5467558)
      Now what the hell is this article about?

      It's about how GNU/Linux is violating SCO patents to make a more responsive desktop experience for the user when playing videos, etc. At least, that's what'll be on record when SCO sues IBM for helping them with this 2.6 kernel by stealing their intellectual property. Afterall, everyone knows SCO UNIX was the most responsive multimedia system of it's time. *rolls eyes*.

    • Re:Amazing! (Score:5, Funny)

      by IIRCAFAIKIANAL ( 572786 ) on Saturday March 08, 2003 @01:53PM (#5467623) Journal
      No need to be sarcastic. Just wave your hand over your head and make a wooshing sound and someone will explain it to you...

      Who me? No, I don't know what the hell is going on either.

      *woosh* *woosh*
    • Re:Amazing! (Score:5, Informative)

      by Jugalator ( 259273 ) on Saturday March 08, 2003 @02:14PM (#5467713) Journal
      It's basically about removing sound stutters, jerkiness when moving windows and generally improving window manager performance...
      This improves the X interactivity tremendously. I went back to 2.5.64 base just to verify, and the difference was very noticeable.

      The test involved doing the big kernel compile while moving large xterm, mozilla and sylpheed windows about. With this patch the mouse cursor was sometimes a little jerky (0.1 seconds, perhaps) and mozilla redraws were maybe 0.5 seconds laggy.

      So. A big thumbs up on that one. It appears to be approximately as successful as sched-2.5.64-a5.

      Ingo's combo patch is better still - that is sched-2.5.64-a5 and your patch combined (yes?). The slight mouse jerkiness is gone and even when doing really silly things I cannot make it misbehave at all. I'd handwavingly describe both your patch and sched-2.5.64-a5 as 80% solutions, and the combo 95%.
      This is great for me, too. I played around with some mp3 playing and did the akpm-window-wiggle test. It is definitely the smoothest.
  • huh? (Score:5, Funny)

    by IIRCAFAIKIANAL ( 572786 ) on Saturday March 08, 2003 @01:16PM (#5467432) Journal
    The Linux kernel team is at it again.

    At it again? At what again? That sorta makes it sound like a girls gone wild video or something. Kernel Dev's Gone Wild volume 3, where Ingo and Linus bare their breasts for beads at a Linux user conference in Tampa Bay - no, that's just too strange...

    Oh, one more thing:

    Hello, my name is Ingo Molnar. You killed my father: prepare to die.
    • No no no! (Score:5, Funny)

      by Anonymous Coward on Saturday March 08, 2003 @01:34PM (#5467529)

      My name is Ingo Molnar. You kill -9'd my parent process. Prepare to die()
    • Re:huh? (Score:5, Interesting)

      by arvindn ( 542080 ) on Saturday March 08, 2003 @02:01PM (#5467657) Homepage Journal
      Kernel Dev's Gone Wild volume 3

      Well, here is Linus replying to Molnar's post:

      From: Linus Torvalds
      Subject: Re: [patch] "HT scheduler", sched-2.5.63-B3
      Date: Thu, 6 Mar 2003 09:03:03 -0800 (PST)

      On Thu, 6 Mar 2003, Ingo Molnar wrote:
      > the whole compilation (gcc tasks) will be rated 'interactive' as well,
      > because an 'interactive' make process and/or shell process is waiting on
      > it.

      No. The make that is waiting for it will be woken up _once_ - when the
      thing dies. Marking it interactive at that point is absolutely fine.

      > I tried something like this before, and it didnt work.

      You can't have tried it very hard.

      In fact, you haven't apparently tried it hard enough to even bother giving
      my patch a look, much less apply it and try it out.

      > the xine has been analyzed quite well (which is analogous to the XMMS
      > problem), it's not X that makes XMMS skip, it's the other CPU-bound tasks
      > on the desktops that cause it to skip occasionally. Increasing the
      > priority of xine to just -1 or -2 solves the skipping problem.

      Are you _crazy_?

      Normal users can't "just increase the priority". You have to be root to do
      so. And I already told you why it's only hiding the problem.

      In short, you're taking a very NT'ish approach - make certain programs run
      in the "foreground", and give them a static boost because they are
      magically more important. And you're ignoring the fact that the heuristics
      we have now are clearly fundamentally broken in certain circumstances.

      I've pointed out the circumstances, I've told you why it happens and when
      it happens, and you've not actually even answered that part. You've only
      gone "it's not a problem, you can fix it up by renicing every time you
      find a problem".

      Get your head out of the sand, and stop this "nice" blathering.

      OK, maybe not gone wild as in baring their breasts, but certainly gone wild as in no-holds-barred flamage :)
      • Re:huh? (Score:3, Interesting)

        by Sarcazmo ( 555312 )
        As someone who has had XMMS skip ever since I went to Red Hat 8 (and the newer versions of the lowlatency patches), I can agree with Linus. The screwed up thing is that even renicing X doesn't help, the kernel takes it upon itself to give it the priority back behind your back.

        Red Hat- Because being a beta tester for kernels is cool!

        (I love red hat, I just think AC takes some big risks with the RH kernel wrt controversial patches)
  • Actually... (Score:4, Informative)

    by DataPath ( 1111 ) on Saturday March 08, 2003 @01:18PM (#5467441)
    Actually, Linus's patch doesn't improve things any better than the scheduler patch it is Linus's patch combined with the scheduler patch that make it such a huge improvement. Again... its the COMBO patch that's arousing so much excitement.
    • Re:Actually... (Score:3, Interesting)

      I'm not so sure, 2.5.54 is far slicker on the desktop than 2.4.x (about as responsive as windows, even without dri).
      If this patch is causing great excitement, then I can only assume linux is now more responsive on the desktop than windows.

      Now, if only supermount was in the 2.5 kernel tree........
  • by Anonymous Coward on Saturday March 08, 2003 @01:21PM (#5467456)
    Something forms itself from the silent void of the empty mailing lists and the noisy chaos of the crowded mailing lists. It shapes and protects us, it entertains and challenges us, it aids us in our journey through the ether world of software. It is mysterious; it is at once source code and yet object code. I do not know the name, thus I will call it the Tao of Linux.

    If the Tao is great, then the box is stable. If the box is stable, then the server is secure. If the server is secure, then the data is safe. If the data is safe, then the users are happy.

    In the beginning there was chaos in Unix.

    Tanenbaum gave birth to MINIX. MINIX did not have the Tao.
    MINIX gave birth to Linux 0.1 and it had promise.
    Linux gave birth to v1.3 and it was good.
    v1.3 gave birth to v2.0 and it was better.

    Linux has evolved greatly from its distant cousins of the old. Linux is embodied by the Tao.

    The wise user is told about the Tao and contributes to it. The average user is told about the Tao and compiles it. The foolish user is told about the Tao and laughs and asks who needs it.
    If it were not for laughter, there would be no Tao.
    Wisdom leads to good code, but experience leads to good use of that code.

    The master Cox once dreamed that he was a Kernel. When he awoke he exclaimed: "I don't know whether I am Cox dreaming that I am a Kernel, or a Kernel dreaming that I am Cox!"
    The master Linus then said: "The Tao envelopes you. You shall create great code for Linux."
    "On the contrary," said Cox, "The Tao has already created the code, I will only have to find it and write it down."

    A master was explaining the nature of the Tao to one of his students:
    "Is the Tao in the VM subsystem?" he asked. "Yes," replied the master.
    "Is the Tao in the scheduler?" he queried again. "The Tao is in the scheduler."
    "Is the Tao even in the modules?". "It is even in the modules," said the master.
    "Is the Tao in the Low-Latency Patch?"
    The master frowned and was silent for much time.
    "You fail to understand the Tao. Go away."

    The Tao is the yin and the yang. It is the good and the evil, it is everything and yet it is nothing, it is the beginning and the end.

    The Tao was there at the kernel compile, and it will be there when the kernel panics.

    A novice user once asked a master: "Why compile in C when C++ is more popular?"
    "Why a monolythic kernel when Mach is more popular?"
    "And why use ReiserFS when ext2 is more popular?"

    The master sighed and replied: "Why run Unix when NT is more popular?"
    The user was enlightened.

    A frustrated user once asked a master: "My kernel has panicked, should I post to lkml?"
    "No," replied the master, "You will only bother the Tao."
    "Should I rm -rf?"
    "No, you will have wasted the Tao's time."
    "Well should I search the web?"
    "You will search for all eternity," said the master.
    "Perhaps I should try FreeBSD?"
    "Then you will have disgraced the Tao."
    "I suppose I could try gdb," said the user.
    The master smiled and replied: "Then you will have made the Tao stronger."

    A stubborn user once told a master: "I run version 2.2. I always have, and I always will."
    The master replied: "You are foolish and do not understand the Tao. The Tao is dynamic and ever changing. Linux strives for the perfection that is the Tao. It flows from version to version with peace."

    "So my Linux does not have the Tao, so what?" said the foolish user. "Oh your Linux is of the Tao," said the master. "However, the Tao of Linux follows the Tao of the C library. One day the C library will change, and your Linux will be left behind." The user was silent.

    An angry user once yelled at a master:

    "My Linux has panicked! What lousy software it is, I hate it so!"
    "You are insulting the Tao," said the master. "The Tao is everywhere bringing order to hundreds of networks, aiding thousands of users, and fighting that of which we call the 'lame.' Do not disrespect the Tao; however, the Tao will forgive you."

    "I apologize," said the user, "And I will be more forgiving the next time the Tao fails me."

    "The Tao has not failed you, it is you that has failed the Tao," said the master. "The Tao is perfect."
    The Tao decides if a kernel shall compile, or if it shall abort.
    The Tao decides if a kernel shall boot, or if it shall freeze.
    The Tao decides if a kernel shall run, or if it shall panic.
    But, the Tao does not decide if a box will have no hardware failures. That is a mystery to everyone.

    A young master once approached an old master: "I have a LUG for Linux help. But, I fail to answer my students' problems; they are above me."
    The master replied: "Have you taught them of the Tao?" he asked. "How it brings together man and software, yet how it distances them apart; how if flows throughout Linux and transcends its essence?"
    "No," exclaimed the apprentice, "These people cannot even get the source untarred."
    "Oh, said the master, "In that case, tell them to RTFM."

    A master watched as an ambitious user reconstructed his Linux.

    "I shall make every bit encrypted," the user said. "I shall use 2048 bit keys, three different algorithms, and make multiple passes."
    The master replied: "I think it is unwise."
    "Why?" asked the user. "Will my encryption harm the mighty Tao, which gives Linux life and creates the balance between kernel and processes? The mighty Tao, which is the thread that binds the modules and links them with the core? The mighty Tao, which safely guides the TCP/IP packets to and from the network card?"
    "No," said the master, "It will hog too much cpu."

    The core is like the part of the mind that is static. It is programmed at a child's creation and cannot be changed unless a new child is made; unless a new kernel is compiled.
    The modules are like the part of the mind that is dynamic. It is reprogrammed every time one learns new knowledge; every time one learns better code.
    One is yin, the other yang. Each is nothing without the other.

    A novice came to lkml and inquired to all the masters there: "I wish to become a master. Must I memorize the Linux header files?"
    "No," replied a master.
    "Must I submit code to Bitkeeper?"
    "No," replied the master.
    "Must I meditate daily and dedicate my life to Linux?"
    "No," replied the master again.
    "Must I go on a quest to ponder the meaning of the Tao?"
    "No. A master is nothing more than a student who knows something of which he can teach to other students."
    The novice understood.
    And thus said the master:
    "It is the way of the Tao."

    A user came to a master who had great status in lkml. The user asked the master: "Which is easier: implementing new features to the kernel or documenting them?"
    "Implementing new features," replied the master.
    The confused user then exclaimed:
    "Surely it is easier to write a few sentences in the man page than it is to write pages of code without error?"
    "Not so," said the master. "When coding, the Tao of Linux opens my eyes wide and allows me to see beyond the code, to let the source flow from my fingers, to implement without flaw. When documenting, however, all I have to work with is a C in high school English."

    He who compiles from the stable tree is stubborn
    and unwilling to change, but is guaranteed reliability.
    He who compiles from the current tree is wise but perhaps too conformist, but is guaranteed steadiness.
    He who compiles from the unstable tree is adventurous and is guaranteed new innovations: some good, some bad.
    He who compiles straight from Bitkeeper is brave but guaranteed turbulence.
    They are all of the Tao. One shall respect the old, and debug the new; none shall argue over which is greatest.

    There once was a user who scripted in Perl: "Look at what I have to work with here," he said to a master of core, "My code is interpreted dynamically, the syntax is unique and simple, I have sockets, strings, arrays, and everything I could ever need. Why don't you stop meddling in C and come join me?"
    The C programmer described his reasoning to the scripter: "Scripting is to C as ebonics is to Latin. If the scripter does not grow beyond that of which he scripts, he will surely {die}. Besides, without C, how can there be script?"
    The scripter was enlightened, and the two became close friends.
  • X11 Beh. (Score:3, Interesting)

    by SirDrinksAlot ( 226001 ) on Saturday March 08, 2003 @01:22PM (#5467466) Journal
    Im sorry, its not the kernel that makes a desktop OS what it is, its the userinterface on top. Linux isnt going to be truely Desktop friendly untill X11 gets replaced with something that doesnt completely suck. You shouldnt need a high end video card to make X11 nice and smooth or have to use a stripped down UI. If Linux wants to set it self apart from all the other OS's its going to need its own desktop engine. I do agree that the 2.6 kernel is going in the right direction, I just belive the rest of the OS is being left really far in the past.

    My 2 1/2 cents Canadian
    • Re:X11 Beh. (Score:5, Insightful)

      by Bert64 ( 520050 ) <bert&slashdot,firenzee,com> on Saturday March 08, 2003 @02:17PM (#5467725) Homepage
      Dropping X11 would be a HUGE mistake. X11 as a system is far more flexible than the gui system of windows, ofcourse this flexibility can introduce a performance hit, but theres many other things in modern os`s which sacrifice performance for features, ease of use, maintainability etc..
      But even considering the larger and more featured system, X11 is as fast, or faster, than windows on all but one of my machines, the one where its slower is because the graphics card is very poorly supported by X.
      What causes slowness more than X11 itself, is the programs running on top of it... KDE for instance, its hardly a speed demon compared to say, windowmaker.
      You dont need a high end videocard to make X smoothe, you just need one that`s well supported... my PCI ATI Rage Pro works perfectly, as does my Elsa GLoria Synergy, both are oldish 8mb pci cards.
      Any system will completely suck with poor drivers, try configuring windows to use generic vga or vesa drivers if you want a laugh.
      X11 is FAR superior to any local-display-only gui system, i have several machines here, and 1 monitor for X, apps running from each machine and displayed here and interacting smoothly with each other and with locally running apps.
      • by Featureless ( 599963 ) on Saturday March 08, 2003 @07:37PM (#5469153) Journal
        Someone comes along and points out X's shortcommings and calls for its replacement. Someone else (who fancies themselves older and/or wiser) comes along and disagrees strenuously, and tries to make X11 out to be the greatest UI ever created. Look... it's "network transparent," it's "flexible," it's "fast," we can just extend it to give it whatever features it lacks, etc. etc.

        Ugh. I don't buy it.

        To put it in perspective, lots of Unix has a big organization problem. X is just emblematic. It's "lower-level" APIs are a big stinking mess. Ever tried to program against it without a super-high-level bit of middleware? Then let's talk about how nice it is. If you're not up on this, try reading JWZ's rants on it (many written as he was porting Netscape)? X is a 4 foot high sandwich of crap, layer after layer between you and the display, full of massive, sucking complexity, the bugs, inefficiency... even during this supposedly wonderful "network transparent" windowing this foul stew shows its colors, as no combination of two applications or X servers quite looks the same. It's a verifiability nightmare, too, of course (and for instance, disabling X's many attempts to listen and talk on the network are one of the first things you do to secure a machine properly - and for real security, you avoid installing X altogether).

        The API design itself is atrocious. The much-touted "flexibility" is really code for laziness - it was a lot of work to do a proper GUI, so no one did it. The mishmash of X server extensions, window managers, font handling systems, etc. that's been cobbled together has led to a nightmare for both programers and users, as any given application doesn't just require "X", but a complex recipe of libraries and versions, and an end-user experience where no two applications look or act the same... or even remotely similar... Where cutting and pasting between windows is a pipe dream, and young geniuses still struggle to configure fonts properly for linux distributors.

        Or to just put it plainly, as my friend (who from time to time would write X windows gadgets) would say, it's only about twice as hard as managing the video memory yourself.

        "And thank god it's not all standardized, or we'd never have had all those wonderful experiments with different ways to do a GUI that never actually happened." In practice, no system is immune from its initial design choices, and it's been an endless series of awful MacOS knockoffs, multi-button madness, color-pallete spinning goofiness. Is X11 a "GUI experimenters toolbench?" Then I think it's time for something a little more grounded in everyday realities of computer use.

        I'm not even warmed up yet. I mean, X is still peppering the filesystem with a hedge-maze of exotically formatted text files describing the hex colors of every pixel of the trim of every window for a variety of appliations and classes in a complex inheritance and assignment scheme that few X developers even understand. Check it out, your XDefaults are "human readable."

        Shall we even discuss its security model?

        Modern Linux has tried to make its peace with X through wrappers, and we write against Tcl/Tk, Qt, inside the Gnome or KDE framework, and yet still the focus groups come back crying... we try to blame overfamiliarity with windows, but the problems are bigger... all of Unix (and of course Linux) suffers from the same class of problems that X does; as, for instance, an application needs to prompt you to insert a series of CD's, but there is no "single, authoritiative, standard" place to go find out what CD drives are installed on the computer, and what their device names are (yes, we know what they _usually_ are), and finding out if any of the CDs are already inserted involves parsing the text output of a proc file or a mount command, and so on and so forth... And all of this is being done by a messy bash script... so it's no surprise this functionatlity is broken even in, for instance, RedHat's own v8 package manager... I hope you can grasp the metaphor.

        It's a mess. Patches won't clean it up. Frankly, it's time we took the whole GUI back to the drawing board. But even if MacOS is the end-all/be-all, we can do it a hell of a lot better than we do in X.

        Following are some choice quotes from Don Hopkins' [] essay:

        X-Windows is the Iran-Contra of graphical user interfaces: a tragedy of political compromises, entangled alliances, marketing hype, and just plain greed. X-Windows is to memory as Ronald Reagan was to money. Years of "Voodoo Ergonomics" have resulted in an unprecedented memory deficit of gargantuan proportions. Divisive dependencies, distributed deadlocks, and partisan protocols have tightened gridlocks, aggravated race conditions, and promulgated double standards.

        X has had its share of $5,000 toilet seats -- like Sun's Open Look clock tool, which gobbles up 1.4 megabytes of real memory! If you sacrificed all the RAM from 22 Commodore 64s to clock tool, it still wouldn't have enough to tell you the time. Even the vanilla X11R4 "xclock" utility consumed 656K to run. And X's memory usage is increasing.


        X was designed to run three programs: xterm, xload, and xclock. (The idea of a window manager was added as an afterthought, and it shows.) For the first few years of its development at MIT, these were, in fact, the only programs that ran under the window system. Notice that none of these program have any semblance of a graphical user interface (except xclock), only one of these programs implements anything in the way of cut-and-paste (and then, only a single data type is supported), and none of them requires a particularly sophisticated approach to color management. Is it any wonder, then, that these are all areas in which modern X falls down?


        As a result, one of the most amazing pieces of literature to come out of the X Consortium is the "Inter Client Communication Conventions Manual," more fondly known as the "ICCCM", "Ice Cubed," or "I39L" (short for "I, 39 letters, L"). It describes protocols that X clients ust use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late -- by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past.

        The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn't work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It's so difficult, that many of the benefits just aren't worth the hassle of compliance. And when one program doesn't comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release.

        In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry's standard naked emperor.

        Using these toolkits is like trying to make a bookshelf out of mashed potatoes.
        - Jamie Zawinski


        The fundamental problem with X's notion of client/server is that the proper division of labor between the client and the server can only be decided on an application-by-application basis. Some applications (like a flight simulator) require that all mouse movement be sent to the application. Others need only mouse clicks. Still others need a sophisticated combination of the two, depending on the program's state or the region of the screen where the mouse happens to be. Some programs need to update meters or widgets on the screen every second. Other programs just want to display clocks; the server could just as well do the updating, provided that there was some way to tell it to do so.


        What this means is that the smarter-than-the-average-bear user who actually managed to figure out that

        snot.fucked.stupid.widget.fontList: micro

        is the resource to change the font in his snot application, could be unable to figure out where to put it. Suzie sitting in the next cubicle will tell him, "just put it in your .Xdefaults", but if he happens to have copied Fred's .xsession, he does an xrdb .xresources, so .Xdefaults never gets read. Susie either doesn't xrdb, or was told by someone once to xrdb .Xdefaults. She wonders why when she edits .Xdefaults, the changes don't happen until she 'logs out', since she never reran xrdb to reload the resources. Oh, and when she uses the NCD from home, things act `different', and she doesn't know why. "It's just different sometimes."

        Joe Smartass has figured out that XAPPLRESDIR is the way to go, as it allows him to have separate files for each application. But he doesn't know what the class name for this thing is. He knows his copy of the executable is called snot, but when he adds a file Snot or XSnot or Xsnot, nothing happens. He has a man page which forgot to mention the application class name, and always describes resources starting with '*', which is no help. He asks Gardner, who fires up emacs on the executable, and searches for (case insensitve) snot, and finds a few SNot strings, and suggests that. It works, hooray. He figures he can even use SNot*fontList: micro to change all the fonts in the application, but finds that a few widgets don't get that font for some reason. Someone points out that he has a line in his .xresources (or was it a file that was #included in .xresources) of the form *fucked*fontList: 10x22, which he copied from Steve who quit last year, and that of course that resources is 'more specific' than his, whatever the fuck that means, so it takes precedence. Sorry, guy. He can't even remember what application that resource was supposed to change anymore. Too bad.


        On the whole, X extensions are a failure. The notable exception that proves the rule is the Shaped Window extension, which was specifically designed to implement round clocks and eyeballs. But most application writers just don't bother using proprietarty extensions like Display PostScript, because X terminals and MIT servers don't support them. Many find it too much of a hassle to use more ubiquitous extensions like shared memory, double buffering, or splines: they still don't work in many cases, so you have to be prepared to do without them. If you really don't need the extension, then why complicate your code with the special cases? And most applications that do use extensions just assume they're supported and bomb if they're not.

        • X11 developers? (Score:3, Interesting)

          by Hard_Code ( 49548 )
          Are there any X11 developers out there (or at least someone in the know) that can comment on the actual PLANS for XFree? So far I see several legitimate criticisms, one being the hardware access/busy waiting issue, and another being the mess that is the way XFree reads resources. When I was first introduced to X, right off the bat, the fact that it was a "special" application that had its own drivers to do direct hardware access, and the mind-boggling resource system, stood right out at me. Although X is great for many things, and although a lot of people spew hot air about it, I feel there are legitimate outstanding issues. As someone who is highly anticipating Linux kernel 2.6, and the potential for Linux on the desktop, I think these are very valid concerns.

          The XFree86 page is rather spartan, and I get NO idea what the roadmap for XFree looks like.
    • Re:X11 Beh. (Score:3, Interesting)

      by Enahs ( 1606 )
      You shouldnt need a high end video card to make X11 nice and smooth

      By those standards, Apple's OS X really sucks.

  • Say What? (Score:2, Interesting)

    by Ra-Rue ( 248664 )

    How does what Linus and Ingo are doing this time differ from previous approaches such as the low latency patch and real time enhancements?

  • How does this compare to preempt and other desktop friendly kernel patches, such as the low latency patch?

    Is there a slight loss in the case of a large app taking all cpu power? I tried preempt after it was overhyped on slashdot, and found it nice for general desktop usage, but it made quake3 and other cpu hungry games jerky when I tried to play them; I hope it's not the case with that new wonderpatch.
  • by j3110 ( 193209 ) <> on Saturday March 08, 2003 @01:30PM (#5467499) Homepage
    What? I thought the desktop user's dream was Mac OS X.

    Most desktop users don't know what kernel they have. Even users that have Linux say "I have Linux 8.0".

    While I think they'll notice some of this, I think users will see more benefit, and notice very much more, when the kernel is more real-time (pre-empting kernel code).
    • While I think they'll notice some of this, I think users will see more benefit, and notice very much more, when the kernel is more real-time (pre-empting kernel code).

      Um. Wouldn't the pre-emptable kernel patch be rolled into this too? Isn't that a done problem? Of course, RTLinux isn't rolled in, but an RTOS isn't exactly necessary for an acceptable desktop. I guarantee that I don't know what I'm talking about, but you sound like you don't either.
    • Actually, if you need *guranteed* maximum time, like in a real-time OS, _average_ performance will be much *worse*.

      A lot more important work is to ensure "fairness", so that no processes is very slow, and in particular that near-real time processes (like playing a movie, 1/30th of a second is not real-time, it could render it _way_ faster) get "enough" time to make it play smoothly.

      From what I've been able to gather, both have been greatly improved in 2.6...

    • While I think they'll notice some of this, I think users will see more benefit, and notice very much more, when the kernel is more real-time (pre-empting kernel code).

      Actually, the huge benefits from running CONFIG_PREEMPT have mostly disappeared from 2.5. When the preempt patches were coming out for 2.4, we noticed huge differences in performance, but that's mostly due to a lot of rough edges in 2.4 that have largely been addressed in 2.5.

      That doesn't mean that preempt is useless now. On the contrary, having the preempt infrastructure has made it easier to check for a lot of error cases, like functions sleeping with spinlocks held. It's just that turning preempt on in 2.[56] won't suddenly make your box a superdesktop anymore :3

  • by arvindn ( 542080 ) on Saturday March 08, 2003 @01:31PM (#5467512) Homepage Journal
    If the scheduler could "see" what the user is doing, then it could make the desktop appear fabulously responsive, by detecting which program the user is currently looking at. But it can't. So it has to use heuristics based on the behavior of programs wrt. how often they compute/get events etc. Windows tries to blindly give priority to the application that's in the "foreground", and ends up screwing everything else. However, it is really possible to achieve close very good interactivity through clever kernel architecture: Beos did it years ago. Lets see if Linux will do better.

    Note that responsiveness is not something that will scale with increasing processor speed. So these patches could really have an effect in setting the Linux desktop experience apart. Will this help to capture desktop market share? Whoda thunk it :)

    • There is, however, an odd characteristic of Windows NT. I don't know what part of the system is to blame, but the effect from a user's point of view is that "anything I want to do on the local network is more important than anything you want to do on the screen."

      If Windows Explorer (not Internet Explorer, but Windows Explorer, the shell program that displays files and directories on the screen) needs something from the network, and the network is slow in responding, it puts up an hourglass. Even though what it needs is only relevant to the topmost window, it may refuse to let you bring up any other window, either in Explorer _or in any other application_. The condition may persist for large fractions of a minute.

      The same thing sometimes occurs accessing files on slow media (diskette or CD-ROM).
      • How to fix this: (Score:3, Informative)

        by nuxx ( 10153 )
        This happens because Explorer is typically a single process, and if something is taking a while, it drags down that process. If you want to fix this in 2000 and XP, go into any old Exporer window, pick Tools -> Folder Options -> View, then check the box marked 'Launch folder windows in a separate process'. This has the effect of spawning a new process (perhaps forking?) for each Explorer window, eliminating hangs if a particular drive or network resource is misbehaving. The only reason I can see why this isn't enabled by default is the cost of additional memory, but it's very much worth it.
  • Written in march 2000... The only UNIX is Linux []

    And I Quote "All the others are A) going to go away or B) be merged into Linux. Linux is simply a more competitive paradigm. When IBM, HP, SUN, DEC (Compaq) and every other PC, Computer embeded device run Linux - the market pressures to toss out the others will be enormous. They already are, sumoe people like Sun though just don't (want to) get it yet."

    Written in march 2003 ... Dell CIO Says "UNIX is dead" []

    My next prediction is that Microsoft is going to get kicked off the desktop, Thank you.

  • by dj_paulgibbs ( 619622 ) on Saturday March 08, 2003 @01:34PM (#5467526)
    Now, I am a long-time user of Windows, but am (and have been always) increasingly tempted by switching to a Linux-based distribution, probably Redhat, on my main desktop machine.

    With that lack-of-linux-knowledge, could someone explain why precisly this is a "Significant Interactivity Boost in (the) Linux Kernel"? Thank you.
    • I think the logic goes like this:
      • Linux was a "better" desktop than "Windoze"
      • But the scheduling system on top of which the X server runs kinda sucked, so in reality Linux wasn't such a great desktop
      • "Windoze" has the graphics subsystem "in the kernel" (not true, but still) and that's "bad". Linux uses a different approach (X is a client/server graphics system) that is considered "good" and not "unstable" and not as "sneaky" as "Windoze"
      • Now someone has come up with a way to make the Linux GUI more responsive.
      • So now Linux will be a better desktop than "Windoze".
      • Slashdot readers are predicting Linux will take over the desktop Any Moment Now.
      Apply to some other technical area where Linux is "better" than "Windoze" - lather, rinse, repeat in a few months.
      • But graphics are in the kernel, at least, in the kernel space. Windows NT does this to minimize context switches because graphics demand the most of the computer (for mose users.) While the driver is a loadable module like most drivers these days, and as such is not built into the kernel, it might as well be, since it runs in the kernel's memory space.
    • by jtdubs ( 61885 ) on Saturday March 08, 2003 @01:50PM (#5467607)
      IANAKH (Kernel Hacker), but here's my understanding of it.

      The kernel development team are experimenting with heuristics to determine what processes are "interactive" and to determine "how interactive" those processes are.

      An interactive process is a process which spends a portion of it's time sleeping, waiting for some kind of event, and then needs cpu time quickly after the event happens.

      In this case the events are user input and screen redraw requests.

      So, the trick is that interactive processes don't need any more CPU time than other processes, they just need it very quickly in response to requests. Low latency.

      The question is, how do you determine what processare are interactive, and how interactive they are.

      They have developed a system whereby there are effectively "interactivity points" that can be given to and taken away from a process.

      The act of being woken up from sleeping by an event awards you interactivity points. The act of completely using up lots of timeslices (acting like a CPU-bound process) takes away interactivity points.

      With Linus's new patch, once you've reached a certain threshold of interactivity points, some of your points start going to the process that woke you up. So, if an "interactive" process is always waking up in response to an event from a certain other process, than that other process is also awarded interactivity points.

      In the end, your interactivity points are taken into account when choosing which processes get the CPU.

      So, with this new code, processes which are "interactive" like your X11 apps get more of the cycles they need when they need them, decreasing their latency, and making them appear to work "better."

      Justin Dubs
      • So, with this new code, processes which are "interactive" like your X11 apps get more of the cycles they need when they need them, decreasing their latency, and making them appear to work "better."
        Actually, as I understood it (which may very well be incorrectly), since X is "waking up" the applications it is X that is getting the overflowed "interactivity" and that this is a better solution than to just brute force "nice -10" X (because forcing it into a higher priority makes it look like a cpu-bound batch process, which the scheduler then increases the latency in tradeoff for throughput). Hair splitting I know.
    • by rseuhs ( 322520 ) on Saturday March 08, 2003 @03:35PM (#5468095)
      Running RedHat on a desktop is like running a rackmount as a desktop.

      It can be done, but it's awkard.

      Try SuSE, you get a good desktop and (gasp) consistent config tools in one place. Or try Mandrake, you get the latest desktop and good config tools. Or try Debian, you get an ultra-stable system that can be easily upgraded. Or try Gentoo, you get a faster system on the bleeding edge.

      Just use a real KDE 3.1 on a non-RedHat distribution and you will never look back at MS Windows.

    • If you think about moving a window in terms of drawing dots on the screen you quickly realize it is rather complicated. Lines need to get shifted over, other windows need to know they can no longer certain areas of the screen. Background stuff needs to get redrawn which often means that windows need to be called to redraw.

      Old fashioned managers handled this by simply giving you an outline of the window you were moving and then doing a full screen redraw. The newer system (say the last 10 years) has been to actually do this real time with dozens of small redraws. This is very CPU intesnive. Further there is an accurate measuring device (the human eye) which notices lacks of performance very quickly.

      On a single tasking machine where the computer could dedicate itself to doing this task this still wouldn't present a problem. On a modern OS with dozens of processes running doing things like the above is a scheduling nightmare. A very complicated scheduling system is out because the scheduling system needs to run so many times a second. The result is you need to think of cool tricks to make this work.

      The cool trick that windows thought of was using the notion of "forground" and "background" to and thus giving certain apps a massive CPU advantage while others got little if any attention except when the CPU wasn't busy. The problem with that is that it forces the user to either:

      a) Have extremely unreliable background processes (default for windows NT/2000/XP desktop)

      b) Have an unresponsibe desktop (default for the NT/2000.. server)

      More importanly this forground/background solution doesn't solve the problem of competing demons which are having other types of CPU problems.

      So Linux long ago rejected this cool trick and there is no notion of "forground" and "background". They were going to handle the problem right or not at all. Now with tuning you can make this particular X related problem go away but only at the cost of introducing other problems, and more importanly all you are really doing is covering the symptom of the disease not curing the diesase. The kernel group has figured out a general solution which improves scheduling for all applications without substantially increasing the complexity of the scheduler.

      Unlike many kernel improvements this one will have substantial impact on desktop performance right out of the box when distributions start shipping with the 2.6 series which is why people are excited.
  • I find some things jump a little (e.g. dragging windows around) at the moment (RH8, Athlon MP 1600, GeForce 2) in X.

    On a 475MHz laptop with ATi Rage Pro video, it runs just as smooth as XP does (they both jump a bit when dragging windows around).

    I know this shouldn't happen on the fast PC though. I must have something set up wrongly. Maybe the latest kernel will make it less noticeable though :-)
    • Smoothness when dragging stuff around probably has more to do with the 2D hardware on your graphics adaptor and the drivers for it. Even though this new kernel apparantly will make things feel snappier I still wouldn't be surprised if GUI jumpiness still happens. 3D acceleration seems to be the hot priority right now. Hence Quartz Extreme in OS X, since the video card is being optimized for 3D make everything look like it's 3D.
  • by borg ( 95568 ) on Saturday March 08, 2003 @01:38PM (#5467549)
    Stop stealing that intellectual property from SCO already. Have you no shame? The gig is up: there's no way you could keep putting this stuff out without ripping off the hard working SCO programmers.
  • for all you... (Score:5, Interesting)

    by Anonymous Coward on Saturday March 08, 2003 @01:39PM (#5467555)
    bashing linux/x/kde/whatever speed, I'm willing to bet you've never doen a full build (ala Gentoo) and actually optimized it for your system...have you? KDE 3.1 is as fast or faster than windows XP on my 1ghz took a while to build, but it's well worth it.
    • Re:for all you... (Score:3, Informative)

      by Plug ( 14127 )
      There have been tests run (I'm sorry that I don't have the links) that demonstrate a computer with an optimised kernel/libc6 and i386 everything else runs only about 10% slower than a computer with optimised everything.

      Gentoo, while a great idea, isn't _that_ much faster than other distributions once this fact is taken into account.

      Remember, 20% of the code is run 80% of the time, and you get your big performance increase by optimising that.
  • The patch (Score:2, Interesting)

    by Anonymous Coward
    Is here []

    On Fri, 28 Feb 2003, Andrew Morton wrote:
    > >
    > > Andrew, if you drop this patch, your X desktop usability drops?
    > hm, you're right. It's still really bad. I forgot that I was using distcc.
    > And I also forgot that tbench starves everything else only on CONFIG_SMP=n.
    > That problem remains with us as well.

    Andrew, I always thought that the scheduler interactivity was bogus, since
    it didn't give any bonus to processes that _help_ interactive users
    (notably the X server, but it could be other things).

    To fix that, some people nice up their X servers, which has its own set of

    How about something more like this (yeah, untested, but you get the idea):
    the person who wakes up an interactive task gets the interactivity bonus
    if the interactive task is already maxed out. I dunno how well this plays
    with the X server, but assuming most clients use UNIX domain sockets, the
    wake-ups _should_ be synchronous, so it should work well to say "waker
    gets bonus".

    This should result in:

    - if X ends up using all of its time to handle clients, obviously X will
    not count as interactive on its own. HOWEVER, if an xterm or something
    gets an X event, the fact that the xterm has been idle means that _it_
    gets a interactivity boost at wakeup.

    - after a few such boosts (or assuming lots of idleness of xterm), the
    process that caused the wakeup (ie the X server) will get the
    "extraneous interactivity".

    This all depends on whether the unix domain socket code runs in bottom
    half or process context. If it runs in bottom half context we're screwed,
    I haven't checked.

    Does this make any difference for you? I don't know what your load test
    is, and considering that my regular desktop has 4 fast CPU's I doubt I can
    see the effect very clearly anyway ("Awww, poor Linus!")

    NOTE! This doesn't help a "chain" of interactive helpers. It could be
    extended to that, by just allowing the waker to "steal" interactivity
    points from a sleeping process, but then we'd need to start being careful
    about fairness and in particular we'd have to disallow this for signal


    ===== kernel/sched.c 1.161 vs edited =====
    --- 1.161/kernel/sched.c Thu Feb 20 20:33:52 2003
    +++ edited/kernel/sched.c Wed Mar 5 19:09:45 2003
    @@ -337,8 +337,15 @@
    * boost gets as well.
    p->sleep_avg += sleep_time;
    - if (p->sleep_avg > MAX_SLEEP_AVG)
    + if (p->sleep_avg > MAX_SLEEP_AVG) {
    + int ticks = p->sleep_avg - MAX_SLEEP_AVG + current->sleep_avg;
    p->sleep_avg = MAX_SLEEP_AVG;
    + if (ticks > MAX_SLEEP_AVG)
    + ticks = MAX_SLEEP_AVG;
    + if (!in_interrupt())
    + current->sleep_avg = ticks;
    + }
    p->prio = effective_prio(p);
    enqueue_task(p, array);
  • by giminy ( 94188 ) on Saturday March 08, 2003 @01:47PM (#5467595) Homepage Journal
    Looks like someone is using the server locally on, as it's down...Hopefully they're getting something done at least :).
  • Now that we are on this topic, it might be a good time to ask this question: How can i get my box to boot a 2.5.x kernel?! I am no newbie to kernel configs, it looks like i did everything right, however i am greated by a "Booting linux kernel..." then my HD making noices for about a minute (but no output to console) and then ... nothing .. keyboard unresponsive, no output on console, nothing..

    Is there some magic ingrediant i missed? I know modutils changed, but i don't even seem to get to a point where that could make the slightest difference

    (had this with 2.5.61, .64 and .64-bk3)
  • It's funny how the lkml discussions can be so flamy all the time.. I guess it helps the work to get done if there's a little spice to it. Check out these choice quotes:

    *ingo > I tried something like this before, and it didnt work.
    *linus >You can't have tried it very hard. In fact, you haven't apparently tried it hard enough to even bother giving my patch a look, much less apply it and try it out.
    Are you _crazy_?
    Normal users can't "just increase the priority". You have to be root to do so. And I already told you why it's only hiding the problem.
    Get your head out of the sand, and stop this "nice" blathering.

  • by iamacat ( 583406 ) on Saturday March 08, 2003 @02:01PM (#5467656)
    Which always gave boost to interactive processes by raising internal priority of the ones that didn't take up the whole CPU slice. Remember how jerky Solaris 2.x felt right after Sun killed SunOS 4.x? My BSD-based aqua desktop on the other hand is very responsive, even when playing mp3s AND doing real time video compression in the background.

    Anyway, I hope Linus and Ingo now have some spare time for real dreams of power users with Linux desktops - drivers! I used to run Linux at work and at home (used to, because I got rid of the Intel box at home). Between these two machines, I had an NVIDIA card, lucent WinModem, CLIE, Zaurus and an NTFS partition that wasn't recognized by default Redhat kernel.

    After every kernel upgrade, I had to recompile 5 drivers. CLIE and Zaurus drivers came in the form of patches that usually refused to apply, or caused a hang when the device was attached! Once I tried a 2.5 kernel because it had some features, like suspend and resume that I could really use. While the default configuration built Ok, once I enabled the drivers I wanted, I couldn't get the thing compiled even before applying my patches.

    Yes, you could just run "Redhat operating system", never upgrade the kernel and wait a few months to install a new release. Then you might find binary drivers to download for the kernel for your particular kind and number of CPUs. But the whole point of Linux (on a personal desktop) is to have some fun and try new stuff out easily.

    Linux developers really need to stabalize driver interfaces. I should be able to go to and download the latest kernel *binary*, then install a binary driver from the CD-ROM that came from my NVIDIA card.

    USB and Firewire buses should be exposed by kernel as network interfaces, accessible to user programs through socket API. In this way, USB drivers will be both easier to write/debug AND will not contribute to Oops. For the ultimate of cool, Wine should support Windows USB drivers (my Virtual PC does!) and I should be able to just install Palm and Zaurus desktops and use them rather trying to feed ttyUSBNN to kpilot.

    Having a stable system that doesn't have to be rebooted to Windows to use some unsupported USB device is far more important than raw performance. I wish any system's developers - Linux, *BSD, Darwin, BeOS, etc - would concentrate on this goal before going back to play with cool toys.

  • NT (Score:2, Informative)

    by sql*kitten ( 1359 )
    Linux creator Linus Torvalds recently proposed a patch to offer interactive processes a boost, greatly benefiting the X desktop, as well as music and movie players. O(1) scheduler author Ingo Molnar merged Linus' patch into his own interactivity efforts, the end result nothing short of amazing... The upcoming 2.6 kernel is looking to be a desktop user's dream come true

    The "feature" of biasing the scheduler either towards interactive proceses or to background processes has been around since NT 3.51, if I remember correctly. It was definitely in NT4, released in 1994 (again, IIRC). So, while this is welcome, it's not an innovation, and saying that Linus "proposed" it is misleading.
    • Re:NT (Score:4, Informative)

      by Anonymous Coward on Saturday March 08, 2003 @02:15PM (#5467715)
      The interactivity boost has been in linux from Linux 0.99. This is a new class of boost, increasing interactive proccess priority and helper proccess priority too.
    • Re:NT (Score:3, Insightful)

      by mce ( 509 )
      Noone claimed that Linus invented the technique (besides, Linux too has been using it for some time already). The only claim made about him is that he proposed that the way in which Linux uses it be changed. (It would help to actually read the article.)
  • Patch explanation (Score:3, Informative)

    by Anonymous Coward on Saturday March 08, 2003 @02:20PM (#5467745)
    The previous scheduler was preoccupied with distributing CPU between tasks evenly. That's great, but the problem with an interactive GUI process is that it needs a disproportionally larger amount of CPU to process its events when there are many UNIX domain socket events pending. Because the X11 GUI is single-threaded and synchronous any delay in event processing becomes painfully obvious on the desktop - it results in jerky motion. In the patch the amount of extra CPU for the process is governed by number of tasks in the queue for that process. In moments when the GUI requires the greatest interactivity it generates a lot of socket events and you more or less briefly get greedy scheduling for the X11 server which allows the synchronous GUI events to be processed immediately, resulting in a smoother desktop experience. When the number of events in the queue go back to normal, the X11 process returns to being an "average" CPU consumer.
    But the good thing about the patch is that it will also allow other servers (HTTP, SMTP - not only the X11 server) to be equally interactive and more responsive to external input.
  • Yes, thank you (Score:3, Insightful)

    by mikers ( 137971 ) on Saturday March 08, 2003 @02:34PM (#5467806)
    Nothing like letting a linux box with say Redhat 7.3 (KDE), Evolution, 4 xterms, Mozilla, Galeon, XMMS get jittery.

    Go to xterm, try to unzip a 1 gig zip file (on a HD on that box) and the open mozilla and drag the window around...

    Wait wait wait, mouse quits moving... Then it starts jumping all over the screen. Time for a coffee.

    This is part pager and part interactive task/busy background task thing that these patches try to fix.

    That was a big turn off of the 2.4 kernel for me.

  • by Animats ( 122034 ) on Saturday March 08, 2003 @02:40PM (#5467838) Homepage
    What's being described here is called a priority inversion, [] where a high-priority task makes a request of some service running at a lower priority and gets hung up behind it. Real-time programmers have been dealing with this for decades, with varying degrees of success. A priority inversion bug caused problems with the Mars Pathfinder mission, and had to be patched remotely.

    There are various solutions to this problem. It sounds like the Linux kernel people are trying priority inheritance via the messaging system (local sockets). QNX [] has had that for over a decade. Because QNX does almost everything, including all I/O, by message passing, it has to do this right. In the UNIX world, message-passing was added quite late, in BSD, and X is one of the few interactive programs that uses socket communication on the local machine. Sockets are used mostly to talk across the network. So support for time-critical local sockets isn't very good. UNIX pipes were the original UNIX interprocess communication mechanism, and they were intended as batch-like devices. Sockets look, and work, a lot like pipes. This legacy is the real cause of the problem.

    Of course, the reason Linux users actually want this feature is so that they can play their pirated MP3s in the background while using X-windows.

    • by catenos ( 36989 ) on Saturday March 08, 2003 @05:49PM (#5468687)
      What's being described here is called a priority inversion, where a high-priority task makes a request of some service running at a lower priority and gets hung up behind it.

      Which is wrong. Did you read the article?

      Priority inversion is, as you explained yourself, about a high priority task effectively getting a low priority by being dependend and therefore waiting on a low priority task.

      The article is about tasks at the same priority[1]. The task scheduler distinguishes between interactive and non-interactive tasks in order to improve latency where the user cares.

      Beforehand, the behaviour failed on a slow, loaded system to recognize the X server as interactive, because then X looks like a CPU-hog[2]. That resulted in freezes of several seconds[3]. Simply speaking, the patch solves this by passing some interactivity points between processes.

      You could have easily seen that this is not about priority inversion as one of the suggested work-arounds was to simply increase the niceness of the X process (which wouldn't help, if priority inversion had been the problem).

      Regarding QNX: As good as it is as a RTOS, as bad it fails to do something sensible when you have too much processes at the same priority. Having a reasonably working system presumes that each task is assigned an appropriate priority. Of course, the people at QNX did a decent job on the default priorities.

      [1] It may have an impact on tasks of different priority. I did not care to investigate that aspect, because that is of minor importance to what the patch is about.

      [2] And for the scheduler, interactivity is determined by a process going to sleep often (by waiting for interaction).

      [3] For non-interactive processes it is beneficial to do them in larger hunks, i.e. let 5 seconds other processes do their work, then work 5 seconds, instead of having 0.01 second slices and do the switching all the time.
      • The article is about tasks at the same priority[1]. The task scheduler distinguishes between interactive and non-interactive tasks in order to improve latency where the user cares.

        When you treat tasks differently, you're prioritizing them. All the priority information isn't necessarily encoded into the UNIX-type priority number. This is a nomenclature distinction between "priority" in the formal sense of "who gets the (a) CPU", vs. the classical UNIX representation of priority numbers.

  • by jregel ( 39009 ) on Saturday March 08, 2003 @02:48PM (#5467882) Homepage
    I've been doing some Safari reading since the Slashdot review a couple of weeks ago, and one book I'm reading is Solaris Internals: Core Kernel Components. One very interesting feature of Solaris is the concept of "scheduler classes". The Solaris kernel is fully pre-emptive and multithreaded. Threads are executed as one of four classes:

    Timeshare scheduling class (the default) attempts to evenly share process time across threads.

    Interactive class is used for improving performance with windowing applications.

    System class is used by the kernel.

    Real Time class is used for fixed priority, fixed quantum scheduling.

    Now I'm no kernel hacker and couldn't explain the hardcore details if pressed, but this sounds pretty clever and Solaris is a very neat operating system. These scheduler classes are loaded as modules which strongly suggests that they can be plugged in and replaced if necessary.

    In 2.4 there were patches that provided realtime and low latency scheduling for the kernel. The new O(1) scheduler is getting positive vibes from the developers from what I've read, but does it cover these bases or are patches still required? In other words, does Linux now scale from realtime embedded to low latency desktop to [whatever NUMA systems require]?
  • by maelstrom ( 638 ) on Saturday March 08, 2003 @03:35PM (#5468091) Homepage Journal
    Just so long as it isn't like the scheduling related to us by our OS prof, where one of the early time sharing systems gave a bit of a boost to terminals after they pressed the enter key.

    This way interactive processes gained a slight boost. Of course, they had to rethink their algorithm as soon as someone figured out that by hitting return a lot they could speed up their programs! Oops :)
  • by Corbin Dallas ( 165835 ) on Sunday March 09, 2003 @02:32AM (#5470393) Homepage
    I just manualy added the Linus patch to my kernel sources ( linux-2.4.19-gentoo-r10 ) and I did notice a nice difference. My test was to compile my app ( knights ) in a Konsole with XMMS running and me moving a Konqueror window all around the screen.

    The interactivity still wasn't perfect, but it was noticably better. Now if I can just track down and apply Ingo's patch as well....

"For a male and female to live continuously together is... biologically speaking, an extremely unnatural condition." -- Robert Briffault