[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180206074253.GA19535@localhost.localdomain>
Date: Tue, 6 Feb 2018 08:42:53 +0100
From: Juri Lelli <juri.lelli@...hat.com>
To: Mathieu Poirier <mathieu.poirier@...aro.org>
Cc: Peter Zijlstra <peterz@...radead.org>,
Li Zefan <lizefan@...wei.com>, Ingo Molnar <mingo@...hat.com>,
Steven Rostedt <rostedt@...dmis.org>,
Claudio Scordino <claudio@...dence.eu.com>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Tommaso Cucinotta <tommaso.cucinotta@...tannapisa.it>,
"luca.abeni" <luca.abeni@...tannapisa.it>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2 1/7] sched/topology: Adding function
partition_sched_domains_locked()
On 05/02/18 11:11, Mathieu Poirier wrote:
> On 2 February 2018 at 03:19, Juri Lelli <juri.lelli@...hat.com> wrote:
> > Hi Mathieu,
> >
> > On 01/02/18 09:51, Mathieu Poirier wrote:
> >> Introducing function partition_sched_domains_locked() by taking
> >> the mutex locking code out of the original function. That way
> >> the work done by partition_sched_domains_locked() can be reused
> >> without dropping the mutex lock.
> >>
> >> This patch doesn't change the functionality provided by the
> >> original code.
> >>
> >> Signed-off-by: Mathieu Poirier <mathieu.poirier@...aro.org>
> >> ---
> >
> > [...]
> >
> >> +/*
> >> + * Call with hotplug lock held
> >
> > Is this the one that we can actually check if it's locked with
> >
> > lockdep_assert_cpus_held()
> >
> > ?
>
> Hi Juri,
>
> You are correct - we could call lockdep_assert_cpus_held() but in my
> opinion it would be in a separate patch and probably outside the scope
> of this work. The sole purpose of this patch is to get the
> locking/unlocking operations of mutex sched_domains_mutex out of
> function partition_sched_domains_locked().
Fair enough. I just thought though that, since you are adding the comment
above, we could as well add an explicit check for hotplug lock.
Best,
- Juri
Powered by blists - more mailing lists