On Fri, 19 Nov 2010 11:56:52 +0100 Andrea Suisani <sick...@opinioni.net> said:
> Hi Gustavo, > > On 11/19/2010 11:53 AM, Gustavo Sverzut Barbieri wrote: > > We already have code to launch processes at lower prio, we could > > easily extend to do cgroup as well > > Good to know ! > > /me going to look at actual code > > Andrea problem is that "lower priority" will be shared among all apps. x, all system "Daemons", wm etc. will have a higher priority. as such in my experience, what you REALLY want to do is this: fix up io nice and schedule nice values for all daemons and process into a few groups or layers. i'll list them here: 1. system critical daemons you will need to always work asap in an emergency e.g.: sshd 2. "realtime high priority" daemons and processes that need to get every bit of cpu they want when they want it - only making way for the most system critical in #1. e.g.: pulseuadio 3. "very high priority" daemons and processes that are involved with user interactivity at all times. only give up cpu in favor of those in #1 and #2. e.g.: Xorg, enlightenment (compositor and wm) 4. "high priority multimedia processes" - anything that would play realtime video, music etc. kind of stuff. e.g.: mplayer, xine, totem, rage, enna, games etc. 5. "regular gui (interactive) apps" e.g.: xterm, firefox, openoffice, gedit 6. "backburner processes" - this would be anything you run INSIDE a terminal or anything for helper processes (like thumbnailer daemons), as well as regular system daemons. e.g.: dbus, syslog, portmap, inetd 7. "everything else you don't care much about" when it comes to getting cpu/disk resources. e.g.: gdm, exim4, bind, hald basically you'd want these ordered with nice/ionice levels where the highest priority (lowest nice values) are #1 and the lest are #7 - there is of course room for debate on some levels -the lower priority ones specifically, but the main point here is you ORDER things in irder of their "realtime user impact". sshd need to be at the top moistly because if u have a runaway pulseaudio consuming all your cpu - u'd like sshd to respond asap to sshing in and killing it... but this is up for debate. but i'd keep this as the "ultra-emergency" priority. pulseaudio comes next due to the nature of audio. pulse (may) be mixing audio and piping it to the audio buffers with very very very small buffers and little latency - any good audio system will do that. the problem is audio suffers from HORRIBLE and NOTICEABLE effects if you should "skip" some mixing. your audio crackles or blanks out. graphics is more immune to this thanks to framebuffers simply keeping on showing the same frame for multiple frames - you drop frames and get a bit jerky, but its more acceptable than audio. next down are your core display system and "shell". this is what controls everything on your screen - and renders a composited scene - it needs to get all the resources it needs whenever it needs it as its generally the final output of pretty much everything else. yes it is even more important than your movie or music player. next down are your media apps that are time sensitive - like pulse, but likely have longer buffers. next ware your regular apps and so on. you get the idea. my point here is - that if you are starving your resources (have more scheduled than your cpu and/or disk can keep up with) you need to priorities the things that are most "apparent" to the user (of a desktop, laptop or embedded system). a server of course has different priorities - i am talking of systems where the primary user is there using a screen on the system and interacting with it. the reason e has the "drop normal apps 1 level in priority" is because i've experimented with the above before on REALLY resources starved systems and it REALLy does work. it helps a HUGE amount.the problem is e itself can only control 1 layer of it - the layer between e and apps it runs. it cant make xterm/gnome-terminal/rxvt power the priority of the shell it runs. e cant change the priority of system daemons u have running. i'd REALLY suggest the above as a good read and "Experiment" for anyone building a WHOLE OS... literally go and fix up priorities of everything (remembering that only root can raise priority - so for example set nice value of X and WM u run from the login manager at "-5" - set nice for sshd to "-10"). now use e's "drop priority of apps" feature... you will have amnaged MOSt of the above - maybe some tweaks to installed terminal apps to drop priority of their child processes would help too. so u'll have sshd at -10, x+e at -5, multimedia etc., apps at -4 ... e doesnt have a way of differentiating between 2 classes of regular apps - but that'd be possible and based on .desktop file key entries it could drop some yet another level to -3. xterm etc. can drop their children now from -3 to -2 - all your normal daemons are running at nice 0 by default anyway... so you're good to go. give it a go. on a system with lots of cpu cores and spare processing power u'll never notice. you WILL notice once u start doing "make -j 32" compiles and lots of heavy disk io (rsync) or when video players play full-hd fideo on a lower-end machine. your gui will FEEL so much smoother and more interactive. don't FORGET ionice too - its also important. same applies as above for it as well. > > On Friday, November 19, 2010, Andrea Suisani<sick...@opinioni.net> wrote: > >> Hi All, > >> > >> I was wondering if somebody is following the on-going discussion > >> about exploiting the group scheduling[1] kernel feature (available > >> since 2.6.24) to increase "user desktop experience" (I'm not saying > >> that e17 is slow, on the contrary it makes bite the dust to gnome/kde > >> on my system :-). > >> > >> Basically Mike Galbraith post a kernel patch [2] to lmkl > >> to implement automatic TTY-based group scheduling (see [3] > >> for a detailed discussion), . > >> > >> In short, this patch automatically creates a group attached to each TTY > >> in the system. All processes with a given TTY as their controlling terminal > >> will be placed in the appropriate group; the group scheduling code can then > >> share CPU time between groups of processes as determined by their > >> controlling terminals. > >> > >> During the aforementioned discussion Lennart Poettering post a > >> user space trick [4] to achieve the same behaviour without patching > >> the kernel. > >> > >> This "trick" is simply a metter of adding 4 lines to your ~/.bashrc: > >> > >> if [ "$PS1" ] ; then > >> mkdir -m 0700 /cgroup/cpu/$$ > >> echo $$> /cgroup/cpu/$$/tasks > >> fi > >> > >> and add those 3 to your rc.local > >> > >> mkdir -p /cgroup/cpu > >> mount -t cgroup cgroup /cgroup/cpu -o cpu > >> mkdir -m 0777 /cgroup/cpu > >> > >> I've used it on my own system and I can say that it works > >> (if your work-flow involved quite often launching tasks > >> from a terminal). > >> > >> Now I'm wondering if Everything could be modified in such a way > >> it could take the advantages of this kernel feature, providing an > >> interface to the user to group tasks based on some custom criteria > >> or simply automatically group task based on some defaults. > >> > >> Obviusly if I had the C skill to do it by myself, I would bite... > >> but unfortunately it's not the case :P > >> > >> Andrea > >> > >> [1] http://lwn.net/Articles/240474/ > >> [2] http://thread.gmane.org/gmane.linux.kernel/1062787 > >> [3] http://lwn.net/SubscriberLink/415740/0b54c2b876c89d3a/ > >> [4] http://thread.gmane.org/gmane.linux.kernel/1063263 > >> > >> > >> > >> > >> ------------------------------------------------------------------------------ > >> Beautiful is writing same markup. Internet Explorer 9 supports > >> standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2& L3. > >> Spend less time writing and rewriting code and more time creating great > >> experiences on the web. Be a part of the beta today > >> http://p.sf.net/sfu/msIE9-sfdev2dev > >> _______________________________________________ > >> enlightenment-devel mailing list > >> enlightenment-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >> > > > > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today > http://p.sf.net/sfu/msIE9-sfdev2dev > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
