Linux

I upgraded my workstation to Linux 2.6.23 mainly to try the Completely Fair Scheduler. The machine compiles code, plays music, runs a browser with an unreasonable number of pages, and occasionally hosts a virtual machine. Under a large parallel build, the old setup could make switching desktops feel as though the keyboard had been sent by post.

My first test was not clever. I started a build, dragged windows around and declared the new scheduler smoother. Then I rebooted into the older kernel and it also seemed smooth. Human perception is a wonderful measurement instrument if the desired unit is confidence.

For a better comparison, I repeated the same build with the same compiler jobs, timed it, and introduced an interactive task that periodically needed a small amount of processor time. Total build time changed little. The interesting difference was the delay before the interactive task ran when all cores were busy. Large stalls became less frequent with 2.6.23, though disk activity could still make the desktop miserable for entirely different reasons.

CFS approaches scheduling without the old collection of active and expired priority arrays. It tracks each runnable task’s virtual runtime, an adjusted measure of how much processor service that task has received. The task with the smallest virtual runtime is the one most entitled to run next. Runnable tasks are kept in a red-black tree, making that leftmost choice efficient as tasks arrive, block and wake.

The word “fair” needs care. Equal nice levels should receive roughly equal shares over time; it does not mean every task receives an identical slice at every instant. Nice values weight the virtual runtime, so a task with lower priority accumulates entitlement differently and receives a smaller share. Sleeper behavior emerges because a task that blocks stops consuming processor time. When it wakes, it may be behind its competitors and therefore run promptly, within limits intended to prevent absurd advantages.

My naive mental model was that CFS simply gives tiny slices to interactive programs and large slices to compilers. That is not how it identifies interactivity. There is no reliable label saying “this is the music player.” Instead, the accounting rewards tasks that use little processor time and wake to perform brief work. A music player, terminal or window manager often behaves that way, but so can a less noble process.

The scheduler also has to balance two competing costs. Switching too often improves apparent responsiveness but loses time to context switches and cache disruption. Waiting too long lets a runnable task monopolise a processor. CFS uses a target scheduling latency and derives slices from the number and weights of runnable tasks, subject to a minimum granularity. As the run queue grows, it cannot promise that every task runs within the same tiny interval without turning the processor into a context-switching demonstration.

This explains one of my results. With a modest build load, interactive delays stayed short. With a deliberately ridiculous number of runnable jobs, latency grew again. Fair scheduling cannot manufacture processor time. It can distribute scarcity coherently, which is less exciting but more useful.

Another misleading result came from I/O. During linking, the desktop paused even though CFS was selecting processor tasks correctly. The disk queue was saturated and applications blocked waiting for files. Changing the CPU scheduler did not cure that. Likewise, swapping overwhelmed every subtle scheduler difference. Before blaming CFS, I now check whether the delayed task is actually runnable rather than sleeping on storage.

Nice levels behaved more predictably in my tests than before, but group fairness remains a practical concern. If one user starts one processor-bound task and another starts twenty, scheduling every task independently can grant the second user most of the machine. There is work around grouping tasks, but the default desktop case still mostly exposes per-task fairness. The name should not be read as a constitutional guarantee.

I also tried changing scheduler tunables because numbers invite interference. Reducing latency made window feedback slightly sharper under synthetic load and increased context switches. Increasing it helped throughput by an amount too small to distinguish confidently while making the terminal occasionally sticky. The defaults survived my experiments, an outcome that wounded my pride but spared my configuration files.

After a week, I am keeping 2.6.23. The improvement is not that compilations finish magically sooner. They do not. The improvement is that short, waking tasks more often get service without elaborate interactivity heuristics, and nice values map onto a cleaner accounting model. That makes a loaded workstation feel less capricious.

The practical conclusion is to test CFS with repeatable mixed workloads, not window wiggling alone. Separate CPU delay from disk delay, compare distributions of latency rather than one lucky run, and resist tuning until a real workload demonstrates a problem. CFS is a substantial scheduler change, not a performance patch that makes every number smaller. On my machine it makes contention more orderly. Given what computers usually do under pressure, orderly is a fairly ambitious achievement.

I tried to use the KDE 4 beta for a complete workday. This was not an especially fair test, but fairness rarely survives curiosity. By lunch I had restarted Plasma twice and learned that my preferred panel arrangement could not yet be reproduced.

I began by importing settings from my normal KDE 3 account. The desktop behaved strangely: duplicated services appeared in menus, an application opened with the wrong font, and one configuration tool crashed. A clean user account fixed all three. Carrying years of configuration into a beta is not migration testing; it is inviting every old assumption to the same small party.

With clean settings, the underlying session is more stable than the desktop shell suggests. Applications launch, KWin manages windows reliably without effects, and Dolphin handles ordinary file work. Plasma remains the obvious construction site. Widgets can be added but are awkward to position precisely. Panel sizing is limited, and occasionally a widget stops responding until the shell is restarted.

That distinction matters because Plasma replaces several previously separate pieces: desktop icons, panels, applets and their containment. A failure in that young shell makes the whole environment appear dead even when applications and window management continue normally. It is a large architectural bet concentrated in the most visible square centimetres of the screen.

Restarting only Plasma from a terminal usually restored the workspace, which is useful for testing even if it is not a reasonable daily ritual.

I also encountered unfinished integration. Notifications differ between applications, removable devices do not always produce a useful action, and some settings change only after restarting a component. These are not dramatic crashes, but they interrupt the sense that one system is in charge.

After the experiment I returned to KDE 3 for work and kept the beta under a separate account for testing. KDE 4 is close enough that ordinary use finds valuable bugs, but not close enough that an ordinary user should be expected to diagnose them. My conclusion is candid: the beta contains a promising desktop framework and several usable applications, but it is not yet a dependable desktop. Calling it ready would be marketing; calling it hopeless would require ignoring everything beneath the panel.

I built a recent kernel with tickless idle enabled because the laptop fan had begun running while the machine did apparently nothing. I expected the new kernel to become silent by virtue of one configuration option. It did not. The fan is apparently not impressed by release notes.

My naive test was to leave a terminal open, wait a minute, and compare the battery estimate. That number wandered by nearly an hour between readings. I then watched processor usage, which stayed close to zero while the fan continued. Neither test told me what was waking the processor.

The periodic timer tick normally interrupts each processor at a fixed frequency so the kernel can account for time and perform scheduling work. During idle periods, those interrupts wake an otherwise sleeping processor for very little purpose. Tickless idle programs the next timer event instead, allowing a longer uninterrupted sleep. It cannot help if an application or driver requests a timer every few milliseconds.

On my machine, an application polling for status updates was doing exactly that. Closing it reduced wakeups dramatically and the fan eventually slowed. A network driver also produced regular activity when the interface was unused. Disabling the interface for a test separated that problem from the timer configuration.

Measuring several idle intervals also mattered. One short sample could be dominated by mail checking, disk flushing or my own impatient mouse movement.

There are limits to the name. Tickless does not mean the kernel never uses timer interrupts, and the current work mainly avoids ticks while a processor is idle. A busy processor still needs scheduling and accounting. Hardware timer support matters too; unreliable timers can turn a power improvement into missed timeouts or clocks that drift.

The practical lesson is that tickless operation removes one systematic source of wakeups. It does not forgive programs that poll constantly, nor drivers that chatter with hardware for entertainment. I am keeping it enabled because idle residency improved and battery measurements over several complete runs are better. But the useful debugging question is now “who wakes the processor?” rather than “is CPU usage low?” Zero percent can be composed of thousands of tiny interruptions, which is a very computer-like definition of resting.

I enabled KWin’s compositing effects on an older Radeon card tonight. Transparent windows appeared, shadows looked convincing, and moving a terminal promptly turned into an interpretive dance performed at twelve frames per second.

My first response was to disable individual effects at random. Wobbly windows went first, mostly because they looked guilty. Performance improved slightly but resizing still left corruption around the window border. Turning transparency off helped nothing. The decorative suspects had excellent alibis.

The real path is longer. Applications draw their windows, the X server and driver place those results in off-screen storage, and the compositor combines them into the screen image using either OpenGL or XRender. A problem in buffer handling, texture-from-pixmap support, synchronization or damage reporting can therefore resemble a slow effect even when the effect itself does almost no work.

Switching KWin from OpenGL to XRender removed the corruption but used more processor time during movement. That points at the OpenGL driver path rather than at shadows. With a newer Mesa package, OpenGL stopped leaving fragments behind, although it still paused occasionally when opening a large window. Direct rendering tests were useful only as a basic check; a spinning gear is not a compositor workload, no matter how hypnotically one watches it.

I also discovered that forcing every optional visual feature together makes diagnosis unnecessarily difficult. I returned to a plain session, enabled compositing with only shadows, then added effects one at a time. Keeping notes about the backend and driver version made the results reproducible instead of merely emotional.

Compositing is not just confectionery. Drawing the final desktop from managed window images can eliminate ugly exposure repainting and enables useful feedback such as smooth task switching. But it places a great deal of trust in graphics paths that have not received identical testing across cards.

For this machine, XRender is presently the boring and usable choice. OpenGL is the interesting test choice. KWin should detect hopeless combinations conservatively, and drivers must improve before effects can be assumed safe. My conclusion is to report corruption with the exact card, driver and backend, not “KDE is slow.” The latter may feel satisfying, but it gives a developer roughly the diagnostic value of a weather complaint.

I used Dolphin for an afternoon to organise a directory full of source archives. The job required renaming files, opening terminals in several directories, comparing sizes and moving groups into subdirectories. This is exactly the sort of ordinary task that reveals more than a polished screenshot.

My naive attempt was to configure Dolphin until it behaved like my Konqueror file-management profile. I looked for the embedded terminal, detailed per-directory view controls and several service actions. Some were absent; others were simply in different places. I initially treated every missing knob as evidence that Dolphin was too simple.

Once I stopped reconstructing Konqueror, the design made more sense. The places panel, breadcrumb path and split view cover most navigation without exposing the browser machinery. The information panel is useful when it updates promptly. The interface has fewer opportunities to turn into an accidental control room, which is not entirely bad.

Remembering view settings per directory would make that restraint easier to accept for folders with genuinely different purposes.

There are real limitations, though. Keyboard focus between the location bar, places and file view is not always obvious. Preview generation can make a directory feel sluggish, and cancelling it does not seem immediate. A failed file operation gave me less detail than I wanted. Split view is promising, but it needs unmistakable indication of which side will receive the next action. Guessing wrong while moving files is a fine way to learn new vocabulary.

The mechanism behind some differences is that Dolphin is deliberately a file manager, while Konqueror is a host for many components. That narrower job permits a cleaner interface, but it also means a feature does not appear merely because some embeddable part already exists elsewhere in KDE.

I will keep Konqueror for browsing and complicated remote work for now. Dolphin is already pleasant for local files, provided previews are used selectively and I do not demand every historical option on day one. Simplicity is valuable when it removes decisions, not when it removes information needed to recover from a mistake. Dolphin is near that balance, but it has not found it everywhere yet.