linux-kernel - Re: High wake up latencies with FAIR_USER

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 28 Jan 2008 13:27:52 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>
Cc:	Guillaume Chazarain <guichaz@...oo.fr>,
	LKML <linux-kernel@...r.kernel.org>, a.p.zijlstra@...llo.nl,
	dhaval@...ux.vnet.ibm.com
Subject: Re: High wake up latencies with FAIR_USER_SCHED


* Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com> wrote:

> NEW_FAIR_SLEEPERS feature gives credit for sleeping only to tasks and 
> not group-level entities. With the patch attached, I could see that 
> wakeup latencies with FAIR_USER_SCHED are restored to the same level 
> as !FAIR_USER_SCHED.
> 
> However I am not sure whether that is the way to go. We want to let 
> one group of tasks running as much as possible until the 
> fairness/wakeup-latency threshold is exceeded. If someone does want 
> better wakeup latencies between groups too, they can always tune 
> sysctl_sched_wakeup_granularity.

the patch does look like the right thing to do. There's nothing special 
about 'groups' versus 'tasks' in terms of scheduling. And most 
importantly, this solves the behavioral assymetry observed by Guillaume 
as well - which makes it an obvious-to-add regression fix. I've added 
your patch to the scheduler queue.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/