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-next>] [day] [month] [year] [list]
Message-Id: <200801271339.14668.toralf.foerster@gmx.de>
Date:	Sun, 27 Jan 2008 13:39:11 +0100
From:	Toralf Förster <toralf.foerster@....de>
To:	Mike Galbraith <efault@....de>
Cc:	Sam Ravnborg <sam@...nborg.org>, Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org
Subject: Re: (ondemand) CPU governor  regression between 2.6.23 and 2.6.24

Am Sonntag, 27. Januar 2008 schrieben Sie:
> 
> On Sun, 2008-01-27 at 12:00 +0100, Toralf Förster wrote:
> > BTW the dnetc process runs under the user "dnetc" with nice level -19,
> > my process runs under my own user id "tfoerste" therefore I wouldn't expect
> > that both processes got the same processor resources isn't it ? :
> 
> Normal.  Nice level controls cpu distribution _within_ a task group,
> whereas distribution between groups is controlled by cpu_share.  It's
> going to take a while for folks to get used to having two levels of cpu
> distribution.

Ough, does this mean that for a multi-user scenario of 2 non-root users "A" and
"B" each running exactly 1 process with nice level 0 and 19 rerspectively
that both share ~50% of the CPU *and furthermore* that that user "B" does never
ever have a  chance to be nice to user "A" although his process should really
use only those CPU cycles not eated by any other user ?

If the answer is yes what's about extending the current behaviour to consider
(optionally) nice level of running processes in the case where
CONFIG_FAIR_GROUP_SCHED is set ?

But anyway the initial email reports not a regression related to the ondemand
governor.

-- 
MfG/Sincerely

Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3

Download attachment "signature.asc " of type "application/pgp-signature" (190 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ