Matthew Garrett ([info]mjg59) wrote,
@ 2009-07-06 19:04:00
Previous Entry  Add to memories!  Tell a Friend  Next Entry
Entry tags:advogato, fedora

What does the desktop want from the kernel?
I'll be running a session on Wednesday at GCDS to find out what desktop developers would like to see from the kernel. There's a lot of interest in making things easier for file indexers, but if anyone has other problems that could be made easier with some level of kernel support then please turn up. No precise time or location yet, but probably around 3PM at the university. More details forthcoming.


(23 comments) - (Post a new comment)

Better interactive performance
(Anonymous)
2009-07-06 08:27 pm UTC (link)
It really sucks to have trivial background tasks causing stutters in videos, pops in audio, or to have a single IO intensive process such as a subversion update drag the whole desktop to its knees.

For instance, I have a Core 2 Duo E8400 with 8GB RAM and dual 320GB SATA hard drives, not too bad. I just launched a big subversion update and my disks are running around like crazy, meanwhile Firefox is running rather choppy and barely usable, gedit took 10 seconds to launch and took a few seconds after that to become usable. When I tried to close gedit, I got the standard Gnome "process not responding dialog" for a second before it decided to close on its own.

All that with only one demanding task in the background? Its not a big secret that Linux's interactive performance has suffered over the past few releases. A good desktop experience requires better responsiveness than this.

(Reply to this) (Thread)
Re: Better interactive performance
[info]cgwalters
2009-07-06 08:50 pm UTC (link)
I 100% agree, though I think the easiest thing to fix is background system processes like updatedb and packagekit.

In an experimental shell I was working on at one time, it defaulted to "nice 19" for all child processes (and internal worker threads were equivalently set), under the assumption that you didn't care if your compilation or git update took an extra second. Maybe one could hack that into the traditional Unix shells too.

(Reply to this) (Parent)(Thread)
Re: Better interactive performance
[info]printf.net
2009-07-06 09:54 pm UTC (link)
I 100% agree, though I think the easiest thing to fix is background system processes like updatedb and packagekit.

Hey, if we fix indexing to happen incrementally, we won't need to do a brute-force updatedb crawl anymore, and then we've solved both problems at once. :)

(Reply to this) (Parent)
Re: Better interactive performance
[info]lionsphil
2009-07-07 02:09 pm UTC (link)
Neither Firefox nor SVN are background system processes, and I don't see why things I run from a terminal should be assumed to be second-class citizens.

I get the impression that Linux's scheduler doesn't attempt I/O fairness, nor properly count in-kernel I/O time against a processes' time allocation, but I haven't gone source-diving to back that up with facts. If that impression is correct, those might be areas to look at by someone interested in something more in-depth than another quick-fix bodge.

(Reply to this) (Parent)
Re: Better interactive performance
[info]pjc50
2009-07-07 10:05 am UTC (link)
I have a suspicion (not investigated) that your problem in that case is that both svn and FF are trying to be transactional: doing a sync() or fsync() and waiting for the result. That will result in lots of out-of-order writes using up all your disk bandwidth.

This sort of thing is hard to fix as it requires work up and down the software stack, including things outside the application developer's POSIX comfort zone.

(Reply to this) (Parent)(Thread)
Re: Better interactive performance
[info]lionsphil
2009-07-07 01:57 pm UTC (link)
And, of course, the whole ext4 excitements mean that people are telling eachother to use sync() even more if you want a filesystem that can actually make anything even vaguely approximating a transactional guarantee.

(Reply to this) (Parent)
Ummm...
(Anonymous)
2009-07-06 09:36 pm UTC (link)
In-kernel sound mixing, FreeBSD-style.

(Reply to this) (Thread)
Re: Ummm...
[info]broonie
2009-07-07 07:51 am UTC (link)
Why? There's serious drawbacks with a pluggable sound architecture like ALSA and all the problems with getting it right and robust exist in both user and kernel space.

(Reply to this) (Parent)
No thanks
[info]http://www2.apebox.org/wordpress/
2009-07-06 10:21 pm UTC (link)
PLEASE let's not forget servers - I already suffer from chronic headaches at work caused by the idiot oom_killer and its desktop-friendly "oh, I'll let every process draw straws" attitude to whether or not to kill the process eating 16 gig of RAM

(Reply to this) (Thread)
Re: No thanks
[info]printf.net
2009-07-06 10:34 pm UTC (link)
Not just servers -- we run out of RAM on the OLPC, and it would be nice to give Sugar a warning (a simple one-bit "yes, you're running out of memory quickly" signal is a fine start) that it should get state saved and then kill something unless it wants the kernel to go ahead with normal OOM. Since Sugar knows which processes are essential and which don't have any unsaved state (or even any state at all), it's in an excellent position to make that decision.

(Reply to this) (Parent)
Limited user access to real-time scheduling
[info]jmspeex
2009-07-07 02:41 am UTC (link)
What I've wanted for quite a while from the kernel is allowing a "normal user"'s task to be scheduled as real-time (SCHED_FIFO), but *only* as long as it's well behaved. The ideal behaviour would be to make the scheduler totally fair despite the giving tasks real-time scheduling. For example, if there are 10 tasks competing for the CPU, an audio app asking for real-time priority, would get it as long as it doesn't try using more than 10% of the CPU time. I'm not sure something that good is possible, but the closer we can be, the better.

The problem right now is that you have to choose between not allowing RT at all, or allowing users to either hang or at least severely impact the machine's performance.

The reason I'm looking for that is that I'm currently writing an audio codec (CELT) that can have as low as 2ms algorithmic delay, but it's impossible to properly use it without being root (or setting security limits).

(Reply to this) (Thread)
Re: Limited user access to real-time scheduling
[info]zdzichubg.jogger.pl
2009-07-07 07:04 am UTC (link)
RealtimeKit seems to solve your problem. No kernel modification required.

(Reply to this) (Parent)(Thread)
Re: Limited user access to real-time scheduling
[info]jmspeex
2009-07-07 02:46 pm UTC (link)
RealtimeKit does not solve the problem. It's better than nothing -- any may be the best achievable in user space, but it's far from perfect. It can't really ensure fairness without having access to kernel internals and it can't adequately protect the system without waking up dozens of times per second. As far as I know, there used to be two patches that were doing something like that in userspace. One was from Con Kolivas, and the other from from Ingo and it got dropped when the rtlimits stuff got merged in 2.6.12.

(Reply to this) (Parent)

[info]printf.net
2009-07-07 03:54 am UTC (link)
Oh, and while we're making a list — we've talked about this on IRC, but it's possibly worth mentioning here:

I'd like a way to advise the kernel to try and pin the contents of a directory tree in the dcache/page cache, because I'm going to want fast read access to it later (because it's a git tree, perhaps). If this turns out to be an unreasonable request for whatever reason, it's fine to discard it then.

This might be more useful for me, being too stingy to buy an SSD, than for The Desktop in general.

(Reply to this)

Multimedia keyboards
(Anonymous)
2009-07-07 04:13 am UTC (link)
Some keys on these shiny USB multimedia keyboards are still not recognized at kernel level. I've got a Logitech Wave keyboard here but cannot use the extra keys in Compiz nor Gnome.


For some explanations from someone technically more competent than me, see here:
http://ubuntuforums.org/archive/index.php/t-565032.html (http://ubuntuforums.org/archive/index.php/t-565032.html)

(Reply to this) (Thread)
Re: Multimedia keyboards
[info]fooishbar
2009-07-07 01:48 pm UTC (link)
Most of that summary is wildly incorrect. If, as he says, you can get scancodes out of evtest just fine and xev, then it's quite obviously a bug in X: specifically, the upper keycode limit of 255. (Note that all the non-working keys have keycodes above 255.) This is being fixed as we speak.

(Reply to this) (Parent)
Resume uevent
(Anonymous)
2009-07-07 05:53 am UTC (link)
uevent on resume so that applications that want to do something intelligent (NetworkManager) don't have to rely on a pile of shell scripts (pm-utils) telling them about it. I suppose a suspend uevent might be interesting too if you could infer the time the system suspended. Maybe that could be part of the resume uevent somehow.

(Reply to this)


[info]pjc50
2009-07-07 12:23 pm UTC (link)
On the subject of the kernel, is there a "My machine has crashed. How do I submit a useful bug report?" guide somewhere? I ask as I managed to crash a server today, probably with gdb.

(Reply to this)


[info]lionsphil
2009-07-07 02:15 pm UTC (link)
Seeing as people are posting end-user things, CPU speed scaling needs love too, if Ubuntu is anything to go by (it may be that they've shipped a stupid configuration). Try it with something like scrolling down a webpage with an arrow key on an Eee, and you get hideous accelleration effects as it takes a second or two for Linux to actually get around to speeding the processor up. (Windows does not have this problem on the same hardware.)

(Reply to this) (Thread)

[info]ajaxxx
2009-07-07 08:42 pm UTC (link)
This is only kind of a CPU scaling bug. The problem is that memory gets downclocked at sufficiently low P states, but the GPU needs that memory bandwidth to, you know, do stuff.

(Reply to this) (Parent)
I'm not a developer
(Anonymous)
2009-07-08 08:50 am UTC (link)
...so these aren't real needs but:

"Sub user support" - it would be nice to be able to create on the fly sub users (e.g. 1000:1) and any tasks running as these sub users are only capable of interaction with other sub user tasks (or normal tasks allowed to communicate with that sub user).

"Easier way to find kernel bugs" - I wish there were some magic options that I could turn on that would make the kernel say "report this to the developer and they'll be able to see your problem exactly. So far I've had issues that other people haven't been able to reproduce and I haven't been able to get the information they need to them either. Whatever method it is would ideally not generate spurious reports either (I hate looking bad).

"Slightly quieter boot" : I'm pretty sure I always see a message like:
[sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
when I am booting even though I'm using the quiet option.

A magic way to know that I am using sensible compilation options for my kernel (it's hand built and I do things like turning off support for other x86 CPUs, using a LOWMEM only kernel etc).

A good way of visualizing I/O load at a per process level (maybe this already exists).

The ability for uvcvideo not to be on by default (or toggled on when accessed).

A good way of visualizing current interactivity levels (although it can be argued that latencytop does this already).

(Reply to this) (Thread)
Re: I'm not a developer
(Anonymous)
2009-07-08 08:51 am UTC (link)
I almost forgot - a way for the digital beep not to keep being interrupted every few seconds. It's as if the hardware is powering down and then back up so you get these blips...

(Reply to this) (Parent)
Re: I'm not a developer
(Anonymous)
2009-07-08 08:52 am UTC (link)
Oh yeah - CPU scaling on the original EeePCs. Somehow the driver never materialized because it could be done via ACPI or something.

(Reply to this) (Parent)

(23 comments) - (Post a new comment)

Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…