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] [day] [month] [year] [list]
Date:	Wed, 30 May 2012 17:34:33 +0200
From:	Juri Lelli <juri.lelli@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	tglx@...utronix.de, mingo@...hat.com, rostedt@...dmis.org,
	oleg@...hat.com, fweisbec@...il.com, darren@...art.com,
	johan.eker@...csson.com, p.faure@...tech.ch,
	linux-kernel@...r.kernel.org, claudio@...dence.eu.com,
	michael@...rulasolutions.com, fchecconi@...il.com,
	tommaso.cucinotta@...up.it, nicola.manica@...i.unitn.it,
	luca.abeni@...tn.it, dhaval.giani@...il.com, hgu1972@...il.com,
	paulmck@...ux.vnet.ibm.com, raistlin@...ux.it,
	insop.song@...csson.com, liming.wang@...driver.com,
	jkacur@...hat.com, harald.gustafsson@...csson.com
Subject: Re: [PATCH 13/15] sched: add bandwidth management for sched_dl.

On 05/29/2012 02:31 PM, Peter Zijlstra wrote:
> On Tue, 2012-05-29 at 14:18 +0200, Juri Lelli wrote:
>>> The thing is, keeping it separate makes for an impossible configuration
>>> scenario. Esp. once we enable !root usage. The proposed 5% is very
>>> limiting and regular users won't have sufficient privilege to change it.
>>>
>>
>> Ok, now I understand your point better, and I agree that 5% is hardly
>> usable for !root users. However, I also think this is probably more a
>> system admin problem. I mean, a sys admin that wants his users to play
>> with -deadline scheduling should have thought how to properly set up his
>> system, and the fact that something must be configured by hand to give
>> users a usable system is generally not a so bad idea.
>
> Yes, but lets not make the life of the unsuspecting admin harder than we
> absolutely have to.
>
> Furthermore we should strive to make DL as useful as possible
> out-of-the-box.
>

Ok, I agree on this.

> One way to do this is to have rt and dl bandwidth constraints
> independent and put a 3rd combined limit in place. But what is the
> benefit of that over a single combined limit?

In the end, a single limit is probably better. So, I'll leave rt_bandwidth
at its default value and make dl_bandwidth a sort of sub-quota of it.
To give the user an out-of-the-box usable system, I could raise dl_bandwith
to, let's say, 40% (of 95%). Thus, in the default scenario, the user will
be allowed to create _rt tasks up to 57% and _dl tasks up to 38% of the
system capacity, sounds reasonable?

Thanks and regards,

- Juri
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ