From: Mike Galbraith <firstname.lastname@example.org> To: Guillaume Chazarain <email@example.com> Cc: Ingo Molnar <firstname.lastname@example.org>, Davide Libenzi <email@example.com>, firstname.lastname@example.org Subject: Re: [patch] sched-2.6.0-test1-G3, interactivity changes, audio latency Date: Sun, 27 Jul 2003 11:31:43 +0200 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <VRC7KGZX0573CW1TPN65C3Y312IC.3f22a7b7@monpc> Hi, At 06:09 PM 7/26/2003 +0200, Guillaume Chazarain wrote: > > - include scheduling latency in sleep bonus calculation. This change > > > > extends the sleep-average calculation to the period of time a task > > spends on the runqueue but doesnt get scheduled yet, right after > > wakeup. Note that tasks that were preempted (ie. not woken up) and are > > still on the runqueue do not get this benefit. This change closes one > > of the last hole in the dynamic priority estimation, it should result > > in interactive tasks getting more priority under heavy load. This > > change also fixes the test-starve.c testcase from David Mosberger. > >Right, it solves test-starve.c, but not irman2.c. With sched-G4, when irman2 >is launched, a kernel compile could take ages, I tried it. After 3 hours it >was still with the first file (scripts/fixdep.c), it produced no .o file. >With the patch at the end a kernel compile takes one hour (with -j1 and -j16) >versus five minutes when nothing else runs (config: allnoconfig). > >The idea in the patch is to keep a list of the tasks on the runqueue, without >the one currently running, and sorted by insertion date. Before >reinserting an >interactive task in the active array, we check that no task has waited too >long on this list. Davide, does it implement the interactivity throttle >you had >in mind? > >It's very similar to EXPIRED_STARVING(), but it has the advantage of >considering >all tasks, not only the expired. It seems that with irman2, tasks don't even >have the time to expire. True, irman2 is a very nasty little bugger. Your method works well here. With your patch in test1+G4, I can run irman2 and still have a quite usable system. It could possibly use a little refinement though. If xmms happens to run out of slice at a time when you determine that starvation is in progress, it'll nail the innocent xmms (or other very light task). I went a different route in tackling irman2 to avoid the pain of expiring X (glitch), but really there's no difference between X and xmms... they should both be run RR if you want 100% glitch free operation (and thus would be exempted from punishment under your method, and mine as well) -Mike
next prev parent reply other threads:[~2003-07-27 9:12 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-07-26 16:09 Guillaume Chazarain 2003-07-27 9:31 ` Mike Galbraith [this message] 2003-07-27 10:26 ` Ingo Molnar -- strict thread matches above, loose matches on Subject: below -- 2003-07-25 19:59 Ingo Molnar 2003-07-25 22:58 ` Felipe Alfaro Solana 2003-07-25 23:30 ` Con Kolivas
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [patch] sched-2.6.0-test1-G3, interactivity changes, audio latency' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).