>, Thomas Bogendoerfer <tsbog...@alpha.franken.de>,
>linux-par...@vger.kernel.org, Max Filippov <jcmvb...@gmail.com>,
>linux-ker...@vger.kernel.org, Johannes Berg <johan...@sipsolutions.net>, Dinh
>Nguyen <dingu...@kernel.org>, linux-ri...@lists.infradead.org, Palmer Dabbelt
><pal...@dabbelt.com>, Sven Schnelle <sv...@linux.ibm.com>,
>linux-al...@vger.kernel.org, Ivan Kokshaysky <i...@jurassic.park.msu.ru>,
>Andrew Morton <a...@linux-foundation.org>, linuxppc-dev@lists.ozlabs.org,
>"David S . Miller" <da...@davemloft.net>
Errors-To: linuxppc-dev-bounces+archive=mail-archive....@lists.ozlabs.org
Sender: "Linuxppc-dev"
<linuxppc-dev-bounces+archive=mail-archive....@lists.ozlabs.org>
On Mon, May 30, 2022 at 11:35:10AM +0200, Christian Borntraeger wrote:
>
>
> Am 29.05.22 um 22:33 schrieb Heiko Carstens:
> [...]
> >
> > Guess the patch below on top of your patch is what we want.
> > Just for clarification: if gmap is not NULL then the process is a kvm
> > process. So, depending on the workload, this optimization makes sense.
> >
> > diff --git a/arch/s390/mm/fault.c b/arch/s390/mm/fault.c
> > index 4608cc962ecf..e1d40ca341b7 100644
> > --- a/arch/s390/mm/fault.c
> > +++ b/arch/s390/mm/fault.c
> > @@ -436,12 +436,11 @@ static inline vm_fault_t do_exception(struct pt_regs
> > *regs, int access)
> > /* The fault is fully completed (including releasing mmap lock) */
> > if (fault & VM_FAULT_COMPLETED) {
> > - /*
> > - * Gmap will need the mmap lock again, so retake it. TODO:
> > - * only conditionally take the lock when CONFIG_PGSTE set.
> > - */
> > - mmap_read_lock(mm);
> > - goto out_gmap;
> > + if (gmap) {
> > + mmap_read_lock(mm);
> > + goto out_gmap;
> > + }
> > + goto out;
>
> Yes, that makes sense. With that
>
> Acked-by: Christian Borntraeger <borntrae...@linux.ibm.com>
Looks sane, thanks Heiko, Christian. I'll cook another one.
--
Peter Xu
