linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Cedric Le Goater <clg@fr.ibm.com>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: Stewart Smith <stewart@linux.vnet.ibm.com>,
	skiboot@lists.ozlabs.org, benh@au1.ibm.com,
	linuxppc-dev@lists.ozlabs.org,
	Neelesh Gupta <neelegup@linux.vnet.ibm.com>
Subject: Re: [PATCH v3 3/3] powerpc/powernv: remove opal_sensor_mutex
Date: Mon, 30 Mar 2015 12:05:59 +0200	[thread overview]
Message-ID: <55192007.9090000@fr.ibm.com> (raw)
In-Reply-To: <1427698777.28219.3.camel@ellerman.id.au>

On 03/30/2015 08:59 AM, Michael Ellerman wrote:
> On Mon, 2015-03-30 at 08:51 +0200, Cedric Le Goater wrote:
>> On 03/30/2015 04:09 AM, Michael Ellerman wrote:
>>> On Fri, 2015-03-27 at 17:39 +0100, Cédric Le Goater wrote:
>>>> The opal sensor mutex protects the opal_sensor_read call which
>>>> can return a OPAL_BUSY code on IBM Power systems if a previous 
>>>> request is in progress.
>>>>
>>>> This can be handled at user level with a retry.
>>>
>>> It can, but how does it actually look in practice?
>>>
>>> It looks like the only use of opal_get_sensor_data() is show_sensor() in
>>> drivers/hwmon/ibmpowernv.c.
>>>
>>> Because that's a sysfs attribute folks will be generally just dumping 
>>> that with cat, or reading it in a shell script, neither of which will 
>>> cope nicely with EBUSY I think?
>>
>> It won't, I agree but it should only happen when running concurrent cat 
>> commands on the hwmon sysfs files. The event should be rare enough.
> 
> Rare enough maybe, but a real pain in the .. to cope with in a shell script if
> you're trying to automate something.
> 
>> Anyhow, this is not a big issue. We can drop that patch. The real "issue"
>> is the time it takes to get some values back from the FSP. This is what
>> user space has been most surprised about.
> 
> OK. The other option would be to move the mutex into the sysfs show routine, so
> only that is synchronous. That would give you nice behaviour from cat, ie. it
> would sleep on contention but still be killable with ctrl-c.

Let's keep it how it is and see if it is possible to the improve OPAL 
side first. 

I will send you an updated patchset shortly. 

Thanks for the review. 

C.

  reply	other threads:[~2015-03-30 10:06 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-25 17:50 [PATCH] powerpc/powernv: handle OPAL_SUCCESS return in opal_sensor_read Cédric Le Goater
2015-03-25 23:07 ` Stewart Smith
2015-03-26  9:44   ` Cedric Le Goater
2015-03-26 12:58     ` Cedric Le Goater
2015-03-26 16:04       ` [PATCH v2 1/3] powerpc/powernv: convert codes returned by OPAL calls Cédric Le Goater
2015-03-26 16:04         ` [PATCH v2 2/3] powerpc/powernv: handle OPAL_SUCCESS return in opal_sensor_read Cédric Le Goater
2015-03-26 16:04         ` [PATCH v2 3/3] powerpc/powernv: remove opal_sensor_mutex Cédric Le Goater
2015-03-27  9:59         ` [v2,1/3] powerpc/powernv: convert codes returned by OPAL calls Michael Ellerman
2015-03-27 10:36           ` [Skiboot] [v2, 1/3] " Benjamin Herrenschmidt
2015-03-27 10:39             ` Cedric Le Goater
2015-03-27 10:45           ` [v2,1/3] " Cedric Le Goater
2015-03-27 16:39           ` [PATCH v3 1/3] " Cédric Le Goater
2015-03-30  2:05             ` Michael Ellerman
2015-03-30  6:37               ` Cedric Le Goater
2015-03-30  6:54                 ` Michael Ellerman
2015-03-30  6:56                   ` Cedric Le Goater
2015-03-30 10:06                   ` [PATCH v4 1/2] " Cédric Le Goater
2015-03-30 10:06                   ` [PATCH v4 2/2] powerpc/powernv: handle OPAL_SUCCESS return in opal_sensor_read Cédric Le Goater
2015-03-27 16:39           ` [PATCH v3 2/3] " Cédric Le Goater
2015-03-27 16:39           ` [PATCH v3 3/3] powerpc/powernv: remove opal_sensor_mutex Cédric Le Goater
2015-03-30  2:09             ` Michael Ellerman
2015-03-30  6:51               ` Cedric Le Goater
2015-03-30  6:59                 ` Michael Ellerman
2015-03-30 10:05                   ` Cedric Le Goater [this message]
2015-03-27  6:05     ` [PATCH] powerpc/powernv: handle OPAL_SUCCESS return in opal_sensor_read Stewart Smith

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=55192007.9090000@fr.ibm.com \
    --to=clg@fr.ibm.com \
    --cc=benh@au1.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=neelegup@linux.vnet.ibm.com \
    --cc=skiboot@lists.ozlabs.org \
    --cc=stewart@linux.vnet.ibm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).