All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Fontenot <nfont@linux.vnet.ibm.com>
To: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH2/11] Add PRRN Event Handler
Date: Tue, 19 Mar 2013 13:01:16 -0500	[thread overview]
Message-ID: <5148A7EC.70301@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130314085155.GB9841@iris.ozlabs.ibm.com>

On 03/14/2013 03:51 AM, Paul Mackerras wrote:
> On Fri, Mar 08, 2013 at 10:00:09PM -0600, Nathan Fontenot wrote:
>> From: Jesse Larrew <jlarrew@linux.vnet.ibm.com>
>>
>> A PRRN event is signaled via the RTAS event-scan mechanism, which
>> returns a Hot Plug Event message "fixed part" indicating "Platform
>> Resource Reassignment". In response to the Hot Plug Event message,
>> we must call ibm,update-nodes to determine which resources were
>> reassigned and then ibm,update-properties to obtain the new affinity
>> information about those resources.
>>
>> The PRRN event-scan RTAS message contains only the "fixed part" with
>> the "Type" field set to the value 160 and no Extended Event Log. The
>> four-byte Extended Event Log Length field is repurposed (since no
>> Extended Event Log message is included) to pass the "scope" parameter
>> that causes the ibm,update-nodes to return the nodes affected by the
>> specific resource reassignment.
>>
>> This patch adds a handler in rtasd for PRRN RTAS events. The function
>> pseries_devicetree_update() (from mobility.c) is used to make the
>> ibm,update-nodes/ibm,update-properties RTAS calls. Updating the NUMA maps
>> (handled by a subsequent patch) will require significant processing,
>> so pseries_devicetree_update() is called from an asynchronous workqueue
>> to allow rtasd to continue processing events.
>>
>> Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
> 
> [snip]
> 
>> +static s32 update_scope;
> 
> Do we have a guarantee that there can only be one of these events
> outstanding at a time?  If so it would be nice to document that in a
> comment next to this declaration, so we know in future that this is
> why this is safe.
> 

We only allow for one event to be outstanding. When a PRRN Event is
received we flush any work currently queued up and add the new event
event to the workqueue (see prrn_schedule_work() from the patch).

As I understand flush_work(), this would wait for any work in flight
to complete, then remove all work before returning. I'll add a comment
and update the patch description.

-Nathan

  reply	other threads:[~2013-03-19 18:02 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-09  3:56 [PATCH 0/11] NUMA CPU Reconfiguration using PRRN Nathan Fontenot
2013-03-09  3:59 ` [PATCH 1/11] Expose pseries devicetree_update() Nathan Fontenot
2013-03-14  8:49   ` Paul Mackerras
2013-03-09  4:00 ` [PATCH2/11] Add PRRN Event Handler Nathan Fontenot
2013-03-14  8:51   ` Paul Mackerras
2013-03-19 18:01     ` Nathan Fontenot [this message]
2013-03-09  4:01 ` [PATCH 3/11] Move architecture vector definitions to prom.h Nathan Fontenot
2013-03-14  8:52   ` Paul Mackerras
2013-03-09  4:02 ` [PATCH 4/11] Add platform_has_feature() Nathan Fontenot
2013-03-14  8:56   ` Paul Mackerras
2013-03-19 18:03     ` Nathan Fontenot
2013-03-14  8:59   ` Paul Mackerras
2013-03-19 18:05     ` Nathan Fontenot
2013-03-14 13:42   ` Michael Ellerman
2013-03-19 18:15     ` Nathan Fontenot
2013-03-22  3:56       ` Michael Ellerman
2013-03-09  4:03 ` [PATCH 5/11] Update numa.c to use platform_has_feature() Nathan Fontenot
2013-03-09  4:04 ` [PATCH 6/11] Update CPU maps Nathan Fontenot
2013-03-09  4:05 ` [PATCH 7/11] Use stop machine to update cpu maps Nathan Fontenot
2013-03-09  4:07 ` [PATCH 8/11] Update numa cpu vdso info Nathan Fontenot
2013-03-14  9:02   ` Paul Mackerras
2013-03-09  4:08 ` [PATCH 9/11] Re-enable Virtual Private Home Node capabilities Nathan Fontenot
2013-03-09  4:08 ` [PATCH 10/11] Enable PRRN Nathan Fontenot
2013-03-09  4:10 ` [PATCH 11/11] Add /proc interface to control topology updates Nathan Fontenot

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=5148A7EC.70301@linux.vnet.ibm.com \
    --to=nfont@linux.vnet.ibm.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=paulus@samba.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.