Date: Thu, 18 Nov 2010 19:55:05 +0100 From: Lucius Windschuh <lwindschuh@googlemail.com> To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-performance@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org>, FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: TTY task group scheduling Message-ID: <AANLkTimq=5KJb5AGA6H0yA7AWrp%2BHZMRhfH6pnh=_NqA@mail.gmail.com> In-Reply-To: <4CE52177.3020306@freebsd.org> References: <AANLkTinHSX1%2Bs3hrHyDeU2Vfp6zekTe04XkHhTc2jtLv@mail.gmail.com> <4CE50849.106@zedat.fu-berlin.de> <4CE52177.3020306@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2010/11/18 Andriy Gapon <avg@freebsd.org>: > [Grouping of processes into TTY groups] > > Well, I think that those improvements apply only to a very specific usage pattern > and are greatly over-hyped. But there are serious issue if you use FreeBSD as a desktop OS with SMP and SCHED_ULE, or? Because currently, my machine is barely usable if a compile job with parallelism is running. Movies stutter, Firefox hangs. And even nice -n 20 doesn't do the job in every case, as +20 seems not to be the idle priority anymore?!? And using "idprio 1 $cmd" as a workaround is, well, a kludge. I am not sure if TTY grouping is the right solution, if you look at potentially CPU-intensive GUI applications that all run on the same TTY (or no TTY at all? Same problem). Maybe, we could simply enhance the algorithm that decides if a task is interactive? That would also improve the described situation. Regards, Lucius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimq=5KJb5AGA6H0yA7AWrp%2BHZMRhfH6pnh=_NqA>