From: Juri Lelli <juri.lelli@redhat.com>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: rjw@rjwysocki.net, linux-kernel@vger.kernel.org,
viresh.kumar@linaro.org, Sudeep Holla <sudeep.holla@arm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Ingo Molnar <mingo@kernel.org>,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
Morten Rasmussen <morten.rasmussen@arm.com>
Subject: Re: [PATCH V5 1/2] base/drivers/arch_topology: Replace mutex with READ_ONCE / WRITE_ONCE
Date: Thu, 29 Nov 2018 13:40:38 +0100 [thread overview]
Message-ID: <20181129124038.GG4271@localhost.localdomain> (raw)
In-Reply-To: <d263fdc7-8d15-ab05-40ad-618841b4f4ff@linaro.org>
On 29/11/18 11:02, Daniel Lezcano wrote:
> On 29/11/2018 10:58, Juri Lelli wrote:
> > On 29/11/18 10:18, Daniel Lezcano wrote:
> >> On 29/11/2018 08:04, Juri Lelli wrote:
> >>
> >> [ ... ]
> >>
> >>>> With or without this patch, it is the case:
> >>>>
> >>>> task1 task2
> >>>> | |
> >>>> read("/sys/.../cpu1/cpu_capacity) |
> >>>> | write("/sys/.../cpu1/cpu_capacity")
> >>>> read("/sys/.../cpu2/cpu_capacity) |
> >>>>
> >>>>
> >>>> There is no guarantee userspace can have a consistent view of the
> >>>> capacity. As soon as it reads a capacity, it can be changed in its back.
> >>>
> >>> True, but w/o the mutex task1 could read different cpu_capacity values
> >>> for a cluster (it actually can also with current implementation, we
> >>> should grab the mutex in the read path as well if we want to avoid
> >>> this).
> >>
> >> Even if the mutex is on the read path, the userspace can see different
> >> capacities because it will read the cpu_capacity per cpu directory.
> >>
> >> The mutex will be take when reading cpu0/cpu_capacity, not for
> >> cpu[0-9]/cpu_capacity. Between two reads, a write can happen because the
> >> lock is released in between.
> >>
> >> Do you agree with the patch ? Or do you want me to drop it ?
> >
> > I don't actually have cases at hand that are showing regression with it,
> > I was just trying to understand if we might potentially hit problems in
> > the future. So, I'm not against this patch. :-)
>
> not-not-acked-by ? :)
:-)
I'm not maintaining this, so,
Reviewed-by: Juri Lelli <juri.lelli@redhat.com>
prev parent reply other threads:[~2018-11-29 12:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-27 13:24 [PATCH V5 1/2] base/drivers/arch_topology: Replace mutex with READ_ONCE / WRITE_ONCE Daniel Lezcano
2018-11-27 13:24 ` [PATCH V5 2/2] base/drivers/arch_topology: Default dmips-mhz if they are not set in DT Daniel Lezcano
2018-11-27 13:24 ` Daniel Lezcano
2018-12-03 13:46 ` Dietmar Eggemann
2018-12-04 10:02 ` Daniel Lezcano
2018-11-28 11:44 ` [PATCH V5 1/2] base/drivers/arch_topology: Replace mutex with READ_ONCE / WRITE_ONCE Juri Lelli
2018-11-28 17:54 ` Daniel Lezcano
2018-11-29 7:04 ` Juri Lelli
2018-11-29 9:18 ` Daniel Lezcano
2018-11-29 9:58 ` Juri Lelli
2018-11-29 10:02 ` Daniel Lezcano
2018-11-29 12:40 ` Juri Lelli [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181129124038.GG4271@localhost.localdomain \
--to=juri.lelli@redhat.com \
--cc=daniel.lezcano@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=morten.rasmussen@arm.com \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=rjw@rjwysocki.net \
--cc=sudeep.holla@arm.com \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.