[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y3O3+NK+6/i7re3Q@google.com>
Date: Tue, 15 Nov 2022 16:02:00 +0000
From: Joel Fernandes <joel@...lfernandes.org>
To: Connor O'Brien <connoro@...gle.com>
Cc: 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>,
Juri Lelli <juri.lelli@...hat.com>,
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>
Subject: Re: [RFC PATCH 10/11] torture: support randomized shuffling for
proxy exec testing
On Mon, Nov 14, 2022 at 12:44:21PM -0800, Connor O'Brien wrote:
> > Instead of doing it this way, maybe another approach is to randomize the
> > sleep interval in:
> >
> > */
> > static int torture_shuffle(void *arg)
> > {
> > VERBOSE_TOROUT_STRING("torture_shuffle task started");
> > do {
> > schedule_timeout_interruptible(shuffle_interval);
> > torture_shuffle_tasks();
> > ...
> > } while (...)
> > ...
> > }
> >
> > Right now with this patch you still wakeup the shuffle thread when skipping
> > the affinity set operation.
> >
> > thanks,
> >
> > - Joel
> >
>
> Wouldn't the affinities of all the tasks still change in lockstep
> then? The intent with this patch is to get into situations where the
> tasks have different affinity masks, which I think requires changing
> the behavior of torture_shuffle_tasks() rather than how often it's
> called.
Correct me if I'm wrong, but you are still changing the affinities of all the
tasks at the same time (shuffle_task_list still has all the threads being set
to the same affinity). The difference is with your patch, you occasionally
skip punching a consecutive hole into shuffle_tmp_mask.
I was thinking how you could make this patch more upstreamable, you are right
calling less often is not what you are specifically looking for. However,
would a better approach be to:
a) randomize the shuffle duration.
b) Instead of skipping the set_cpus_allowed_ptr(), why not randomize
the number of times you call cpumask_next() to pick a random hole.
These are just some ideas.
thanks,
- Joel
Powered by blists - more mailing lists