linux-kernel - Re: [PATCH v5 03/15] sched/core: uclamp: map TASK's clamp values into CPU's clamp groups

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181107150430.GL14309@e110439-lin>
Date:   Wed, 7 Nov 2018 15:04:30 +0000
From:   Patrick Bellasi <patrick.bellasi@....com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
        Ingo Molnar <mingo@...hat.com>, Tejun Heo <tj@...nel.org>,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Paul Turner <pjt@...gle.com>,
        Quentin Perret <quentin.perret@....com>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Morten Rasmussen <morten.rasmussen@....com>,
        Juri Lelli <juri.lelli@...hat.com>,
        Todd Kjos <tkjos@...gle.com>,
        Joel Fernandes <joelaf@...gle.com>,
        Steve Muckle <smuckle@...gle.com>,
        Suren Baghdasaryan <surenb@...gle.com>
Subject: Re: [PATCH v5 03/15] sched/core: uclamp: map TASK's clamp values
 into CPU's clamp groups

On 07-Nov 15:55, Peter Zijlstra wrote:
> On Wed, Nov 07, 2018 at 02:48:09PM +0000, Patrick Bellasi wrote:
> > On 07-Nov 14:35, Peter Zijlstra wrote:
> > You mean se_count overflow ?
> 
> Yah..
> 
> > > And I'm not really a fan of hiding that error in a define like you keep
> > > doing.
> > 
> > The #define is not there to mask an overflow, it's there to catch the
> 
> +#define UCLAMP_MAPERR "clamp value [%u] mapping to clamp group failed\n"
> 
> Is what I was talking about.
> 
> > > What's wrong with something like:
> > > 
> > > 	if (SCHED_WARN(free_group_id == UCLAMP_GROUPS))
> > > 		return;
> > 
> > Right, the flow should be:
> > 
> >   1. try to find a valid clamp group
> >   2. if you don't find one, the data structures are corrupted
> >      warn once for data corruption
> >      do not map this scheduling entity and return
> >   3. map the scheduling entity
> > 
> > Is that ok ?
> 
> That's what the proposed does.
> 
> > > and
> > > 
> > > > +	uc_map_new.se_count = uc_map_old.se_count + 1;
> > > 
> > > 	if (SCHED_WARN(!new.se_count))
> > > 		new.se_count = -1;
> > 
> > Mmm... not sure we can recover from a corrupted refcount or an
> > overflow.
> > 
> > What should we do on these cases, disable uclamp completely ?
> 
> You can teach put to never decrement -1 (aka. all 1s).

Still we don't know when re-enable -1 again...

But, with bucketization, this will eventually turns into a small
performance penalty at run-time when a CPU clamp group is going to be
empty (since we will end up scanning an array with some holes to find
out the new max)...  maybe still acceptable...

Will look into that for v6!

Thanks

> But its all SCHED_DEBUG stuff anyway, so who really cares.


-- 
#include <best/regards.h>

Patrick Bellasi