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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Thu, 15 Oct 2020 13:56:09 +0200
From:   Dietmar Eggemann <dietmar.eggemann@....com>
To:     Yun Hsiang <hsiang023167@...il.com>
Cc:     peterz@...radead.org, linux-kernel@...r.kernel.org,
        qais.yousef@....com, patrick.bellasi@...bug.net
Subject: Re: [PATCH v2 1/1] sched/uclamp: add SCHED_FLAG_UTIL_CLAMP_RESET flag
 to reset uclamp

On 14/10/2020 17:00, Yun Hsiang wrote:
> On Tue, Oct 13, 2020 at 10:25:48PM +0200, Dietmar Eggemann wrote:
>> Hi Yun,
>>
>> On 12/10/2020 18:31, Yun Hsiang wrote:

[...]

> The tg uclamp value may also change. If top-app's cpu.uclamp.min change
> to 50 (~500), then task A's effective uclamp min value is 300 not ~500.
> We can set task A's uclamp to 1024, it will be restricted by the tg.
> But when task A move to root group, it's effective uclamp min value
> will be 1024 not 0. If a task is in root group and it doesn't want to
> control it's uclamp, the effective uclamp min value of that task should be 0.
> So I think reset functionality is needed.

OK, looks like the intended solution { a) or b) in
https://lkml.kernel.org/r/87zh4ohnf9.derkling@matbug.net} is not really
feasible.

So we do need the uclamp reset to enable throughout the entire lifetime
of task p 'p is !user_defined -> p is controlled by taskgroup hierarchy)'.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ