Forgot your password?
typodupeerror
X Software GUI Linux

Significant Interactivity Boost in Linux Kernel 673

Posted by CowboyNeal
from the speed-bump-removal dept.
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:
  • by andyp (27347) on Saturday March 08, 2003 @01:14PM (#5467423) Homepage
    Erm, when was the last time you used Linux then? Running GNOME on RedHat 8 here, no problems with cut-and-paste between KDE/GNOME/Motif apps :-)
  • 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
  • by Billy the Mountain (225541) on Saturday March 08, 2003 @01:22PM (#5467468) Journal
    Linux was the fastest platform on the block (back in the days of Windows 3.1 and flawed pentiums). More recently, working with Linux, I was disappointed with the speed. Maybe this will be the killer-non-ap that makes Linux scream and encourages us all to delete their FAT32 partitions for good?

    BTM
  • Re:Actually... (Score:3, Interesting)

    by oliverthered (187439) <olivertheredNO@SPAMhotmail.com> on Saturday March 08, 2003 @01:25PM (#5467474) Journal
    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........
  • Say What? (Score:2, Interesting)

    by Ra-Rue (248664) on Saturday March 08, 2003 @01:28PM (#5467483)

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


  • by j3110 (193209) <samterrellNO@SPAMgmail.com> 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).
  • 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.
  • Doesn't work for me (Score:3, Interesting)

    by Anonymous Coward on Saturday March 08, 2003 @01:39PM (#5467552)
    Except that doesn't work if the X app is being displayed locally but run remotely. Or at least it doesn't seem to.

    Well, okay. Look. I just opened up my X server here on my mac os X box, sshed with X tunneling to my university's Solaris box, opened up xchat, selected some text, and attempted to paste it into a nearby xterm. Oh, hey, guess what, didn't work. I tried what you said. I selected some text, i clicked on the xterm, i tried middle-clicking and right-clicking. Nothing there. Care to tell me what i'm doing wrong?

    Anyway, the whole select-to-copy thing is HORRIBLE GUI design. What if you want to select something in order to edit it without *blowing away* the clipboard? What if your hand slips and you select a couple letters of text by accident before you can paste something important into its destination? I, personally, have intense problems with the copy-paste thing because at some point i picked up the stupid habit of often scrolling by selecting text and dragging off the edge of the window, which will obliterate the textboard. And, worst of all, there's that nagging little question: let's say i'm editing a file, and i want to select some text in the part of the document i'm editing, "cut" it, scoll up to the top of the document, delete part of a paragraph, write a couple lines, and then paste what i just cut. What X's copy/paste means is that i must select the text i want to move to copy (making sure not to delete it yet, becuase it would be too easy to accidentally select text and copy over what i've written, losing it forever), scroll up, click where i want it to go, paste, and then delete and rewrite the text around it, scroll back down, and then delete the text i copied. Yeah, way to go on making the interface fit the needs of the user. Dammit.

    And then there's the fact that, still, mostly due to the broken silliness of X copy&paste, most applications don't quite work the same, becuase they've all fucking implemented the clipboard in nonstandard ways because those unstandard ways are "better". Which they are, unless for some silly reason you want to copy and paste between applications. We've got the "clipboard" and the "cut buffer" and i don't know what either means, and lately some GNOME apps and such have taken to signing up with a sane (i.e., "copy" and "paste" are commands, and as such require a menu use or a key combination). And then vim has like its ten little internal clipboards, and emacs has some clipboard system i don't even pretend to know the first thing about, and i mostly use vim as my text editor in unix. And none of these apps i've ever seen give the option of choosing which copy/paste behavior you want: i mean, none of them will give you a nice little preference that says "select to copy" vs "select 'copy' from menu to copy" vs "have ten little internal cycling cut buffers with some arcane method of manipulation". And i still don't know how copy/paste within vim is supposed to interact with other X apps. I'd test it right now, but for some reason still unknown to me, i can't get gvim to run over my ssh-tunneling setup. When i try, it says:

    X11 connection rejected because of wrong authentication.
    XIO: fatal IO error 32 (Broken pipe) on X server "localhost:13.0"
    after 0 requests (0 known processed) with 0 events remaining.
    The connection was probably broken by a server shutdown or KillClient.


    Maybe it doesn't like my MIT magic cookies, or something? But I digress. Face it. Copy and paste is still the most broken thing about X, and that's saying a lot. And maybe i'm just dense, but i still can't figure out how to change my X keyboard mapping on these silly Solaris boxes.

    -- super ugly ultraman
  • 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 box...it took a while to build, but it's well worth it.
  • The patch (Score:2, Interesting)

    by Anonymous Coward on Saturday March 08, 2003 @01:41PM (#5467562)
    Is here [iu.edu]

    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
    problems.

    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
    handling.

    Linus

    ----
    ===== 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 yamla (136560) <chris@@@hypocrite...org> on Saturday March 08, 2003 @01:46PM (#5467580)

    I am curious... which GUI do you use in Linux? What speed processor and how much RAM do you have? Which distribution (or kernel) of Linux do you use?

    I ask because it has been my experience that Linux is already considerably more responsive (in terms of GUI performance) than Windows. I use KDE 3.1 with Linux 2.4.20 and I have 512 megs of RAM and a 1.46 Ghz processor.

    Now, least people accuse me of trolling (or of pandering to the Linux crowd), I should point out that I am not sure why Windows is so unresponsive. It seems to have something to do with hard drive access. It seems to me that Windows XP is acting like I'd expect it to if I didn't have DMA enabled for my hard drives. Basically, whenever I access the hard drive, the GUI becomes almost completely unresponsive, sometimes taking almost a minute to fire up even a browser. I have checked, though, and I do have DMA enabled.

    So I truly do not know what is going on with Windows, but in Linux I just don't have these problems. Under heavy disk access, it may take a few seconds to fire up a browser in Linux, but that's it. MP3s keep playing, my apps are still responsive, etc. etc.

  • by dpbsmith (263124) on Saturday March 08, 2003 @01:49PM (#5467603) Homepage
    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).
  • by The Bungi (221687) <thebungi@gmail.com> on Saturday March 08, 2003 @01:49PM (#5467604) Homepage
    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.
  • Re:left, no right! (Score:1, Interesting)

    by Anonymous Coward on Saturday March 08, 2003 @01:57PM (#5467641)
    things aren't that black and white anymore. take a machine which is processing video but I want to hit its web server to check status/watch a bit. On my desktop I transcode video but would like to watch video at same time. as it stands now i cannot. a good scheduler would be a godsend for me.
  • 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.

    Linus
    OK, maybe not gone wild as in baring their breasts, but certainly gone wild as in no-holds-barred flamage :)
  • by stubaggs (629456) on Saturday March 08, 2003 @02:27PM (#5467773)
    I always felt that one the advantages of *nix+X over that other OS was that the UI processes where not part of the kernel as a high priority, so that some UI glitch didn't lock the whole machine up. Sure, by doing so, it makes the system feel more responsive (feel responsive=feel faster if you don't know better, this is why M$ did this I propose), but fairly problematic when one of them misbhaves (and you can't switch to a console to kill of a rogue application). Or did I just miss the point ? SB
  • Re:X11 Beh. (Score:3, Interesting)

    by Enahs (1606) on Saturday March 08, 2003 @02:31PM (#5467796) Journal
    You shouldnt need a high end video card to make X11 nice and smooth

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

  • Re:huh? (Score:3, Interesting)

    by Sarcazmo (555312) on Saturday March 08, 2003 @02:35PM (#5467815)
    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)
  • by Animats (122034) on Saturday March 08, 2003 @02:40PM (#5467838) Homepage
    What's being described here is called a priority inversion, [embedded.com] 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 [qnx.com] 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 WNight (23683) on Saturday March 08, 2003 @02:40PM (#5467840) Homepage
    Not quite right. Every multi-tasking system since the first few in the 70s has had the concept of running interactive apps with a higher priority. It's a very obvious improvement.

    The non-obvious improvements are things like making the applications that depend on, or are depended on, by the interactive app, run faster. There are also additional tweaks to this that that are being considered such as giving interactive programs a smaller time-slice, but more of them, so it'll do things like paint the windows properly in respose to your movements, but it won't bog the rest of the system down.

    Technically, scheduling tweaks do add to code complexity, but only in such a tiny way. Linus's patch was five lines. And Linus is very concerned with making sure patches are self-contained and, when possible, aren't spread out, a few lines in many different areas. He's got a very good, very "correct" attitude about design. It comes from him being happy with Linux for years now, he's not rushing to any specific point so it becomes useful. He's willing to put the time in to do it right.

    Anyways, this is to say that most kernel patches don't lead to complexity, most decrease the complexity of the code. Linus has often sent patches back to be done the "right way" instead of allowing a hack. This tweak is so small and self-contained that it can't really be said to add complexity to anything.
  • by ZorinLynx (31751) on Saturday March 08, 2003 @02:44PM (#5467858) Homepage
    I for one happen to love X11's method of copy & paste. It's so much faster and more convenient than under windows. I like being able to simply select something in one window, then middle-click it into another window without having to enter additional keystrokes or menu commands.

    Whenever I'm on a windows box, I groan at having to manually copy after selecting, and not being able to paste with one mouse click.

    Remember one person's UI annoyance is another person's UI bliss. }:) That's why we'll never agree!

  • 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 Anonymous Coward on Saturday March 08, 2003 @02:53PM (#5467897)
    Well said. It's surprising that no one in the Linux camp has done this earlier. This is well known operating systems 101 stuff. Honestly, I've used a similar technique in my own systems with great success for years. I just assumed that Linux already had this feature 5 years ago considering the hundreds of contributers to it. Time to look at the Linux kernel code to find out what other common sense optimizations they missed.
  • Re:Actually... (Score:2, Interesting)

    by Anonymous Coward on Saturday March 08, 2003 @03:25PM (#5468041)
    We have VNC, why does X need to go through TCP/IP to draw a window?

    Do you have any idea how stupid you're sounding right about now? You're trolling, right? First of all, what protocol do you think VNC uses across the network? Yes, that's right: TCP/IP. "Ah," you say "but X uses TCP/IP even on the local system." My response is simple: no, it doesn't. When displaying locally X uses domain sockets, which is just about the fastest way of moving data about inside the system, especially when combined with the shared memory extension.

    There isn't a single justifiable reason for claiming X is inherently slow. Sure, the protocol carries with it a bit of cruft, but that cruft doesn't slow X itself down. It's just the interaction of X with the current linux kernel that isn't as fast as windows. And the combo patch mentioned in this article is meant to solve that problem. That's why it got onto slashdot.

    When a Linux GUI can use things like hardware acceleration, only then will it outperform windows.

    Oh man, welcome to slashdot, where the uninformed spread their beliefs. Hardware acceleration (2D) has been in XFree since the 3.x days, and 3D acceleration is in XFree 4. Ofcourse, you might have misconfigured your system, which is a whole other can of worms (I agree X is still too easy to misconfigure).

    As for why Apple didn't go with X, that's hard to say. Apple likes architectural elegance, and X for all it's power isn't all that elegant. Also, they had to write a lot of code in the graphics layer anyway, since XFree at the time didn't support a lot of what they needed (anti-aliased fonts, transparency, hardware auto-detection). Btw, transparency and decent hardware detection won't hit XFree until version 5.

    Besides, I don't know if you've actually used Mac OS X, but it's GUI performance isn't all that. And it is seriously bloated memory-wise in the graphics layer.
  • My Point (Score:1, Interesting)

    by SirDrinksAlot (226001) on Saturday March 08, 2003 @03:35PM (#5468094) Journal
    The point i was trying to get at is X11 is not End user friendly by any means. Just because it may be powerfull doesnt make it good however most of the time it makes it difficult. Its difficult to configure (something you SHOULD NOT HAVE TO DO) and if you do try to do it by hand its terribly easy to screw up. In regards to the KDE vs WindowMaker someone commented on, I would have to say thats a case of Bloat Vs Streamlined (or stripped). KDE is easier for average Joe to walk up and use then WindowMaker. Since KDE is slow and bloated its also not worth while for Average Joe to use as his primary OS.

    To be a good Desktop OS you need ease of use, at this moment X11 doesnt fit that description. Just because you may think Microsoft or even Apple is evil doesnt mean you shouldnt take design tips from them.
    A possible solution would be a new X11 Compatable system for those who want it and a solid fast easy to use UI for it for those who dont. I also think we need a Unified UI Toolkit so everything across applications is the same.

  • 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.

  • by Kourino (206616) on Saturday March 08, 2003 @03:40PM (#5468125) Homepage

    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 drinkypoo (153816) <martin.espinoza@gmail.com> on Saturday March 08, 2003 @04:04PM (#5468244) Homepage Journal
    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 Trolling4Dollars (627073) on Saturday March 08, 2003 @04:57PM (#5468497) Journal
    This example perfectly illustrates what linus was having problems with when Ingo suggested that users just nice X up. It hides the problem, but doesn't actually fix it. Windows XP plays tricks on users to make them think that it's faster than Win2K or even NT. It loads the GUI earlier than the previous OSes, but there is still a lot of shit happening on the system in the background when you first get to the desktop (services starting, background apps loading, etc...). This is what causes the delay in response to clicking on the Start button. To prove this to a friend with Linux, I set X to start up a lot earlier and disabled a few of the non-critical services in the init scripts and compiled a custom kernel. Total APPARENT boot time from "Joe User's" perspective was about 30 seconds. I have to wonder if it would be a hell of a lot faster with this new patch. The thing is that these changes DON'T actually make the system faster at all. It's pretty much the same as before, but the end-user experience is that it APPEARS faster. That seems to be what a lot of people miss in this discussion.
  • Re:Gaming (Score:2, Interesting)

    by jmweeks (49705) <jose@joseweeks.com> on Saturday March 08, 2003 @05:34PM (#5468643) Homepage

    The way the scheduler determines interactivity is that an application sleeps, i.e. it waits for some sort of user input and then executes based upon that input. Games, at least the type of games that lag, don't meet this definition of "interactivity" and so will see little benefit from this patch.

    These scheduler improvements could be considered comparable to seek time on a disk, while game performance is more akin to burst speed.

  • by Anonymous Coward on Saturday March 08, 2003 @05:50PM (#5468694)
    My Merrill Lynch advisor said Microsoft only has about 4-5 years and then that's it. He said the ML advisors had been given this from an outside source hired by ML to give them a report on the future of Microsoft. Mainly because of loss of high end to Red Hat Linux. I tried to buy $15K of Microsoft, and he advised against it.
  • by Trelane (16124) on Saturday March 08, 2003 @07:20PM (#5469067) Journal
    Horse hockey. I have.

    Lower-end stuff (e.g. xterms) run slower over a dialup link (I'm sure I'm not even getting 40-50 kbps here), but it's entirely usable, particularly if I've been using it for a little while. Netscape 4 was lousy. I just tried it. I'm at 16-bit colour, BTW.

    Back when I had a cable modem (before I moved to a place where they said I'd have a cable modem by the end of last year. hah!), which was capped at 3Mbps, I ran Mozilla 1 over the cablemodem, over a long distance (they hadn't hooked in to KANREN, so my traffic to the university went from Manhattan, KS through Manhattan, NY and back) from my older Ultra10 workstation (It had, I think, just been upped to 256MB RAM), displaying on my Debian (XFree 4? Or was it still 3?) PII 400 w/ 512 MB RAM, and it ran just fine. I don't recall it being substantially slower than local. I was either running 16bit or 24bit depth. Quite possiby 24bit, since I wasn't trying to run many games then (I made it 16bit for games over winex).

    Oh, did I mention that those were over an encrypted connection? (ssh X11 tunneling)

    Heck, the university used Sun IPX/IPC with Linux as thin-clients, displaying from a couple of (actually fairly crummy IIRC) central servers. It was pretty usable, too.

    Slow at 100Mbit my ass.

    And, according to www.ncl.cs.columbia.edu/publications/cucs-022-00.p df [columbia.edu], Microsoft Terminal Svcs is only able to do 8 bits (256 colors). Is that still accurate?
  • by benjamindees (441808) on Saturday March 08, 2003 @08:20PM (#5469311) Homepage
    I could be wrong. I guess most people just want instant gratification (access to the programs they need to run) and a stable, reliable experience for the least cost possible. These seem to be at odds with each other.

    The users I know would trade stability and $10/mo for instant access, so they leave their computers on all the time and they crash once a week. Maybe the users you refer to are more cost-conscious, or maybe they just want stability and would trade the two minutes it takes to boot and log in for a reliable system.

    All I'm saying is that, given the opportunity, anyone would want both reliability and instant-access for zero cost. M$ knows this, and they know their products are not stable, so they market the (fictional) "fast boot times" of their OS's.

  • X11 developers? (Score:3, Interesting)

    by Hard_Code (49548) on Saturday March 08, 2003 @11:06PM (#5469819)
    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.
  • by nitehorse (58425) <clee@c133.org> on Sunday March 09, 2003 @01:13AM (#5470186)
    Heh. And yet in your sig, you link to ReactOS. Hmmm.

    Did you actually read the article? This has nothing to do with foreground processes, and everything to do with making things more responsive for processes that are going to relinquish their locks more quickly. The only reason X is brought up as a demo is because (being a monolithic and single-process beast) it's easiest to notice when X is lagging behind a bit because of the (previous) sucky heuristics.

    The double-whammy of Ingo's patch combined with Linus's little 6-liner is quite impressive. I've got a make -j3 running in my background right now, while I'm running KDE and using the XFree-supplied 'nv' driver (instead of the NVidia supplied one... haven't yet checked to see if NVidia has ported their driver to work with 2.5.x, or if it Just Does [TM]). I can move windows about with better responsiveness than my Win2K install gives me when it's just finished a huge task (compilation of a large project, exiting out of Counter-Strike). This is a very welcome improvement.

    As a side note: Isn't it funny how the users with the higher Slashdot IDs seem to be more MS-friendly than those of us who've been here a while (with a few notable low-UID exceptions).

"The value of marriage is not that adults produce children, but that children produce adults." -- Peter De Vries

Working...