linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Nathan Lynch <nathanl@linux.ibm.com>
To: Juliet Kim <julietk@linux.ibm.com>, linuxppc-dev@lists.ozlabs.org
Cc: mmc@linux.ibm.com, mwb@linux.ibm.com
Subject: Re: [PATCH]powerpc/mobility: Serialize PRRN and LPM in device tree update
Date: Mon, 06 May 2019 12:14:36 -0500	[thread overview]
Message-ID: <87sgtrqzcz.fsf@linux.ibm.com> (raw)
In-Reply-To: <5cc359e9.h9YV36UYX//U5tLh%julietk@linux.vnet.ibm.com>

Hi Juliet,

Juliet Kim<julietk@linux.vnet.ibm.com> writes:
> Fix extending start/stop topology update scope during LPM
> Commit 65b9fdadfc4d ("powerpc/pseries/mobility: Extend start/stop
> topology update scope") made the change to the duration that 
> topology updates are suppressed during LPM to allow the complete 
> device tree update which leaves the property update notifier
> unregistered until device tree update completes. This prevents
> topology update during LPM.  
>
> Instead, use mutex_lock, which serializes LPM and PRRN operation 
> in pseries_devicetree_update.

I think this is conflating two issues:

1. Insufficient serialization/ordering of handling PRRNs and
   LPM. E.g. we could migrate while processing a PRRN from the source
   system and end up with incorrect contents in the device tree on the
   destination if the LPM changes the same nodes. The OS is supposed to
   drain any outstanding PRRNs before proceeding with migration, which
   is a stronger requirement than simple serialization of device tree
   updates. If we don't impose this ordering already we should fix that.

2. The NUMA topology update processing. Generally speaking,
   start/stop_topology_update() enable/disable dt_update_callback(),
   which we use to update CPU-node assignments. Since we now know that
   doing that is Bad, it's sort of a happy accident that
   migration_store() was changed to re-register the notifier after
   updating the device tree, which is too late. So I don't think we
   should try to "fix" this. Instead we should remove the broken code
   (dt_update_callback -> dlpar_cpu_readdd and so on).

Do you agree?


Thanks,
Nathan


  reply	other threads:[~2019-05-06 17:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-26 19:20 [PATCH]powerpc/mobility: Serialize PRRN and LPM in device tree update Juliet Kim
2019-05-06 17:14 ` Nathan Lynch [this message]
2019-05-07 20:47   ` Juliet Kim
  -- strict thread matches above, loose matches on Subject: below --
2019-04-26 19:19 Juliet Kim
2019-04-26 19:06 Juliet Kim
2019-04-26 16:08 Juilet Kim
2019-04-26  4:32 Juilet Kim

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=87sgtrqzcz.fsf@linux.ibm.com \
    --to=nathanl@linux.ibm.com \
    --cc=julietk@linux.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mmc@linux.ibm.com \
    --cc=mwb@linux.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).