linux-kernel - Re: [RFC PATCH 07/11] sched: Add proxy execution

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]

Message-ID: <Y0aM9T600RUlR8PI@localhost.localdomain>
Date:   Wed, 12 Oct 2022 11:46:29 +0200
From:   Juri Lelli <juri.lelli@...hat.com>
To:     Joel Fernandes <joel@...lfernandes.org>
Cc:     Connor O'Brien <connoro@...gle.com>, linux-kernel@...r.kernel.org,
        kernel-team@...roid.com, John Stultz <jstultz@...gle.com>,
        Qais Yousef <qais.yousef@....com>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Valentin Schneider <vschneid@...hat.com>,
        Will Deacon <will@...nel.org>,
        Waiman Long <longman@...hat.com>,
        Boqun Feng <boqun.feng@...il.com>,
        "Paul E . McKenney" <paulmck@...nel.org>, youssefesmat@...gle.com
Subject: Re: [RFC PATCH 07/11] sched: Add proxy execution

On 12/10/22 01:54, Joel Fernandes wrote:

...

> > +migrate_task:
> > +	/*
> > +	 * The blocked-on relation must not cross CPUs, if this happens
> > +	 * migrate @p to the @owner's CPU.
> > +	 *
> > +	 * This is because we must respect the CPU affinity of execution
> > +	 * contexts (@owner) but we can ignore affinity for scheduling
> > +	 * contexts (@p). So we have to move scheduling contexts towards
> > +	 * potential execution contexts.
> > +	 *
> > +	 * XXX [juril] what if @p is not the highest prio task once migrated
> > +	 * to @owner's CPU?
> 
> Then that sounds like the right thing is happening, and @p will not proxy()
> to @owner. Why does @p need to be highest prio?

No, indeed. I (now :) don't think the above is a problem.

> > +	 *
> > +	 * XXX [juril] also, after @p is migrated it is not migrated back once
> > +	 * @owner releases the lock? Isn't this a potential problem w.r.t.
> > +	 * @owner affinity settings?
> 
> Juri, Do you mean here, '@p affinity settings' ?  @p's affinity is being
> ignored right?

Yeah, @p affinity.

> > +	 * [juril] OK. It is migrated back into its affinity mask in
> > +	 * ttwu_remote(), or by using wake_cpu via select_task_rq, guess we
> > +	 * might want to add a comment about that here. :-)
> 
> Good idea!

Connor, maybe you can add such a comment in the next version? Thanks!

> I am also wondering, how much more run-queue lock contention do these
> additional migrations add, that we did not have before. Do we have any data
> on that? Too much migration should not negate benefits of PE hopefully.

Looks like this is a sensible thing to measure.

Best,
Juri