ULatencyD Enters The Linux World

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

[TiborB]

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

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

[kbios]

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

That depends. If you are running it inside a container und the container system allows you to use cgroups, that should be fine.
If it is run on the host, you surely need a new scheduler configuration that takes into account that a process never ever gets moved outside the container it was created. I never looked into the namespace stuff, so i can honestly say: i don't know.
In general, it can work, at least it can be configured that way :-)

[kbios]

That depends. If you are running it inside a container und the container system allows you to use cgroups, that should be fine.
If it is run on the host, you surely need a new scheduler configuration that takes into account that a process never ever gets moved outside the container it was created. I never looked into the namespace stuff, so i can honestly say: i don't know.
In general, it can work, at least it can be configured that way :-)

Thanks for your reply! I checked my setup and I found that all container processes are children of lxc-start. So would it be possible to write a rule (is it this what you mean with "new scheduler configuration"?) that prevents process that are child of lxc-start from being manipulated by ulatencyd? I searched the docs but I couldn't find anything like this. Thanks

[TiborB]

Hi Poelzi,
thanks for you prompt respond.

I installed today's version and indeed it is more verbose. Also, I started it from within Xserver and no crash this time.

I have another questions ...

1) What if I start (by mistake or by chance) second instance of ulatencyd?

2) what if there are two Xservers run on one box?

3) I must admit I'm not much familiar with cgroups and even what exactly your tool is doing. So I dont understand how your tool knows which application is "good" and which is "bad". For example, how it distinguishes opera from linuxdcpp or from some mp3 playing program... The active windows is not allways the right test, because mp3 player might not be in active window yet it needs some preference. Or do you have some list of applications split into some groups?

4) Do you trust ulatencyd that it would not do any serious harm? In other words, can I put it in the list of services started after boot of my box?

5) Is it possible to measure effect of ulatencyd? Probably not I think...

So these are my questions that accumulated in my head during the day

For your information - perhaps you can mentioned it somewhere - I found that for Arch Linux two PKGBUILDS were created in AUR (arch linux users will understand what it means) - ulatencyd and ulatencyd-git (http://aur.archlinux.org/packages.php)

That is all I have , thanks

Tibor

[TiborB]

thanks for you prompt respond.

I installed today's version and indeed it is more verbose. Also, I started it from within Xserver and no crash this time.

I have another questions ...

1) What if I start (by mistake or by chance) second instance of ulatencyd?

2) what if there are two Xservers run on one box?

3) I must admit I'm not much familiar with cgroups and even what exactly your tool is doing. So I dont understand how your tool knows which application is "good" and which is "bad". For example, how it distinguishes opera from linuxdcpp or from some mp3 playing program... The active windows is not allways the right test, because mp3 player might not be in active window yet it needs some preference. Or do you have some list of applications split into some groups?

4) Do you trust ulatencyd that it would not do any serious harm? In other words, can I put it in the list of services started after boot of my box?

5) Is it possible to measure effect of ulatencyd? Probably not I think...

So these are my questions that accumulated in my head during the day

For your information - perhaps you can mentioned it somewhere - I found that for Arch Linux two PKGBUILDS were created in AUR (arch linux users will understand what it means) - ulatencyd and ulatencyd-git (http://aur.archlinux.org/packages.php)

That is all I have , thanks

Tibor

[TiborB]

sorry for double post, it was confused because the first one did not show up immediately after I posted it..

I have small comment to your FAQ 1.1. Your command returns here

ERROR: Unknown user-defined format specifier "cgroup".

Probably my ps is not new enough, ps -V returns:

procps version 3.2.8

This is neither your problem nor big problem, but some users can also run into this.... I just note that I have up-to-date arch linux

[poelzi]

ERROR: Unknown user-defined format specifier "cgroup".

Probably my ps is not new enough, ps -V returns:

procps version 3.2.8

This is neither your problem nor big problem, but some users can also run into this.... I just note that I have up-to-date arch linux

It seems that debian has patches for cgroups support that are not official.
Once i get time to write user programs i will add something that shows that :-)