ULatencyD Enters The Linux World

[kbios]

linux-containers conflicts?

Hi, I would like to try ULatencyD, but on the FAQ I read "You will not be able to run a different cgroups agent in parallel." Does this mean I will have problems with the linux-containers I'm using?
Thanks

[poelzi]

Hi, I just run into your project and installed it immediately... It looks very interesting...

I have few questions:

1. First time I run it it crashed my box, xserver hangt, I had to reboot the box. Second time I run it from virtual text terminal, this time without problems. Was it just coincidence?

That is extremely strange. Most likely the x server crashed when the xwatch plugin
connected to the xserver, but I really don't see why. The worst thing that can happen is that some garbage cookie would be send, but the x server really should not crash there.

2. I run ulatencyd with -vv, but it printed messages only after start and no message since. Is it correct behavior? If it is, how can I know it is doing anything?

I added some checks for the system capabilities on trunk. could you test there again. The debug levels changed, so -vv will print debug output now, and then at least every interval which is 10 secs default you should see some output.

3. Is common user supposed to edit any config file or anything?

If you don't have cgroups mounted on some special place, there is nothing to do.
See the Faq.

[TiborB]

few questions

Hi, I just run into your project and installed it immediately... It looks very interesting...

I have few questions:

1. First time I run it it crashed my box, xserver hangt, I had to reboot the box. Second time I run it from virtual text terminal, this time without problems. Was it just coincidence?

2. I run ulatencyd with -vv, but it printed messages only after start and no message since. Is it correct behavior? If it is, how can I know it is doing anything?

3. Is common user supposed to edit any config file or anything?

OK, that is all I have for now, take care

Tibor

[Yfrwlf]

First: the system does not work with the active window pid itself. it has a active processes list which contains the last n processes active. default config is 5, so when you switch between two programs which is very common, these two will both be in the active group.

so, even when x will not set the property on the menu windows, the focus information is not lost.

there are already rules that add ui apps of kde and gnome to a ui group that has more priority then any other running program, so switching desktops etc always feels fast.

xserver itself is placed in the group system.essential which gets lots of cpu shares.

Sounds like a pretty good set-up. Have something to make the focused process get the most attention, something to give other recently-active processes a lot of attention, and something to give all of the core UI processes high priority. I think tweaking that basic structure would be pretty much most all that is needed as far as process priority.

Rest of the improvements for desktop responsiveness I'd think would be in anticipation of app launching by pre-loading, memory pre-allocation, hard disk data structuring to become more readily available (grouping most often used apps close together), and general app speed-ups utilizing multi-threading/parallelization and removing bloat and such.

[poelzi]

When you browse menus the active window doesn't lose focus, at least not in Gnome. All of GTK, the entire interface, needs to have responsiveness above what any running program gets. I assume for this to happen you would need to make sure Xorg gets top priority, and perhaps some other things like gnome-panel for Gnome and similar for KDE.

Xorg sure does use a lot of CPU. I wonder just how CPU-hungry Wayland will be in comparison. :P

First: the system does not work with the active window pid itself. it has a active processes list which contains the last n processes active. default config is 5, so when you switch between two programs which is very common, these two will both be in the active group.

so, even when x will not set the property on the menu windows, the focus information is not lost.

there are already rules that add ui apps of kde and gnome to a ui group that has more priority then any other running program, so switching desktops etc always feels fast.

xserver itself is placed in the group system.essential which gets lots of cpu shares.

[Yfrwlf]

I just wanted to inform, that i made a real release 0.3.1

It got a lot of features since the project announcement. This release contains a plugin that detects the process of the active x window and gives those more cpu shares. And much more...

https://github.com/poelzi/ulatencyd/downloads

There is now a ubuntu PPA.

When you browse menus the active window doesn't lose focus, at least not in Gnome. All of GTK, the entire interface, needs to have responsiveness above what any running program gets. I assume for this to happen you would need to make sure Xorg gets top priority, and perhaps some other things like gnome-panel for Gnome and similar for KDE.

Xorg sure does use a lot of CPU. I wonder just how CPU-hungry Wayland will be in comparison. :P

[poelzi]

I just wanted to inform, that i made a real release 0.3.1

It got a lot of features since the project announcement. This release contains a plugin that detects the process of the active x window and gives those more cpu shares. And much more...

https://github.com/poelzi/ulatencyd/downloads

There is now a ubuntu PPA.

[gilboa]

Seriously, before all this, Linux had much worse multitasking capabilities than Windows 2000 did. Very happy to see this getting fixed.

I like Windows 2K, a-lot. It was the last Windows OS on my workstation.
.... However,
You seem to mix "multi-tasking" and "interactive performance".

Linux is -very- good at juggling huge amount of process on large amount of processing cores, In fact, it's -far- better than Windows Server 2K8 (Let alone Windows 2K).
However, as a desktop OS, Linux, at least out-of-the-box, is less optimized for interactive performance. (What is usually called responsiveness)

On the other hand, I spent parts of the weekend working (including gaming...) on my Xeon workstation while 16 out of the 24 (hyper)threads were busy compressing a 1.5TB storage into an external USB drive using tar+pbzip, so I guess Linux is not that bad when it comes to interactive performance....

- Gilboa

[thorgt]

I'd like to make two points.
Point one:
Guys, what are you talking about? Do you even realise a bunch of students can't write an OS scheduler! It's Operating System Science, a lot of research has been put into it, it's a highly theoretical and a very complex matter. It's not done overnight or in any way fast.
Point two:
Desktop latency is a very complex issue, spawning across numerous subsystems, and the disorganised approach we have now in Linux, with new scheduler variants appearing every day, a few control daemons, and now this ULatencyD daemon being developed without necessary synchronisation and unified planning. Take a look at the Windows approach, for example:there the scheduler talks to the window manager and to some other subsystems, such as I/O and don't remember what else, dynamically adjusting itself and the process timeslice to the current situation. However, it is desktop-oriented, and this is where the window manager ties and the general quantum calculation and distribution algorithms originate. So we need to tackle this issue in a more broad and integrated way (not to be messed up with generic, that's another thing), and less UNIX/Linux (distributed/independent development) way, if you want.

This is what I mean:imagine some guy comes and says, "I want to introduce a mechanism for providing window manager feedback into the kernel a la Windows scheduler." Imagine the flame that comes right next to this? "It's not generic enough! We can't rely on a window manager in the kernel! We chanbge window managers every day! You're making too many assumptions, and this s not how Linux and UNIX in general is developed! Go go go develop your non-generic code somewhere else but not here! Never will it be included in the kernel!" And so on and so forth. We're too generic, and that's our problem. Sometimes you need to make compromises and develop something less generic and more exact, but solving some certain problem well instead of trying to be a jack of all trades and not succeeding in any of the problems you're trying to solve.

[KDesk]

I have to agree with Yfrwlf on this one. Even windows 2000 felt more "snapier" (that seems to be a popular word these days) than recent linux (until at least version .34). Just the fact that, when something heavy is going on in the background (high disk i/o, high cpu load) it takes a few seconds from the moment you click on something to it actually responding to the click speaks a lot about the responsiveness problem. This is something that apple got right: it must feel fast (even if it isn't).

Completely agree with you. Windows has no big problem when copying some data from a disc, it works most of the time. And Mac OS X is relay good on this, that's why many graphics and sound producers use it without thinking twice. Using iOS is a pleasure, the GUI is more responsive than a PC.

The GUI tasks should have a high priority, mainly the front window; audio should have a high priority too.