[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YpCsBwFArieTpvg2@gmail.com>
Date: Fri, 27 May 2022 12:46:31 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Peter Xu <peterx@...hat.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Richard Henderson <rth@...ddle.net>,
David Hildenbrand <david@...hat.com>,
Matt Turner <mattst88@...il.com>,
Albert Ou <aou@...s.berkeley.edu>,
Michal Simek <monstr@...str.eu>,
Russell King <linux@...linux.org.uk>,
Ivan Kokshaysky <ink@...assic.park.msu.ru>,
linux-riscv@...ts.infradead.org,
Alexander Gordeev <agordeev@...ux.ibm.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Jonas Bonn <jonas@...thpole.se>, Will Deacon <will@...nel.org>,
"James E . J . Bottomley" <James.Bottomley@...senpartnership.com>,
"H . Peter Anvin" <hpa@...or.com>,
Andrea Arcangeli <aarcange@...hat.com>,
openrisc@...ts.librecores.org, linux-s390@...r.kernel.org,
Ingo Molnar <mingo@...hat.com>,
linux-m68k@...ts.linux-m68k.org,
Palmer Dabbelt <palmer@...belt.com>,
Heiko Carstens <hca@...ux.ibm.com>,
Chris Zankel <chris@...kel.net>,
Peter Zijlstra <peterz@...radead.org>,
Alistair Popple <apopple@...dia.com>,
linux-csky@...r.kernel.org, linux-hexagon@...r.kernel.org,
Vlastimil Babka <vbabka@...e.cz>,
Thomas Gleixner <tglx@...utronix.de>,
sparclinux@...r.kernel.org,
Christian Borntraeger <borntraeger@...ux.ibm.com>,
Stafford Horne <shorne@...il.com>,
Michael Ellerman <mpe@...erman.id.au>, x86@...nel.org,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
Paul Mackerras <paulus@...ba.org>,
linux-arm-kernel@...ts.infradead.org,
Sven Schnelle <svens@...ux.ibm.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
linux-xtensa@...ux-xtensa.org, Nicholas Piggin <npiggin@...il.com>,
linux-sh@...r.kernel.org, Vasily Gorbik <gor@...ux.ibm.com>,
Borislav Petkov <bp@...en8.de>, linux-mips@...r.kernel.org,
Max Filippov <jcmvbkbc@...il.com>,
Helge Deller <deller@....de>, Vineet Gupta <vgupta@...nel.org>,
Al Viro <viro@...iv.linux.org.uk>,
Paul Walmsley <paul.walmsley@...ive.com>,
Johannes Weiner <hannes@...xchg.org>,
Anton Ivanov <anton.ivanov@...bridgegreys.com>,
Catalin Marinas <catalin.marinas@....com>,
linux-um@...ts.infradead.org, linux-alpha@...r.kernel.org,
Johannes Berg <johannes@...solutions.net>,
linux-ia64@...r.kernel.org,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Dinh Nguyen <dinguyen@...nel.org>, Guo Ren <guoren@...nel.org>,
linux-snps-arc@...ts.infradead.org,
Hugh Dickins <hughd@...gle.com>, Rich Felker <dalias@...c.org>,
Andy Lutomirski <luto@...nel.org>,
Richard Weinberger <richard@....at>,
linuxppc-dev@...ts.ozlabs.org, Brian Cain <bcain@...cinc.com>,
Yoshinori Sato <ysato@...rs.sourceforge.jp>,
Andrew Morton <akpm@...ux-foundation.org>,
Stefan Kristiansson <stefan.kristiansson@...nalahti.fi>,
linux-parisc@...r.kernel.org,
"David S . Miller" <davem@...emloft.net>
Subject: Re: [PATCH v3] mm: Avoid unnecessary page fault retires on shared
memory types
* Peter Xu <peterx@...hat.com> wrote:
> This patch provides a ~12% perf boost on my aarch64 test VM with a simple
> program sequentially dirtying 400MB shmem file being mmap()ed and these are
> the time it needs:
>
> Before: 650.980 ms (+-1.94%)
> After: 569.396 ms (+-1.38%)
Nice!
> arch/x86/mm/fault.c | 4 ++++
Reviewed-by: Ingo Molnar <mingo@...nel.org>
Minor comment typo:
> + /*
> + * We should do the same as VM_FAULT_RETRY, but let's not
> + * return -EBUSY since that's not reflecting the reality on
> + * what has happened - we've just fully completed a page
> + * fault, with the mmap lock released. Use -EAGAIN to show
> + * that we want to take the mmap lock _again_.
> + */
s/reflecting the reality on what has happened
/reflecting the reality of what has happened
> ret = handle_mm_fault(vma, address, fault_flags, NULL);
> +
> + if (ret & VM_FAULT_COMPLETED) {
> + /*
> + * NOTE: it's a pity that we need to retake the lock here
> + * to pair with the unlock() in the callers. Ideally we
> + * could tell the callers so they do not need to unlock.
> + */
> + mmap_read_lock(mm);
> + *unlocked = true;
> + return 0;
Indeed that's a pity - I guess more performance could be gained here,
especially in highly parallel threaded workloads?
Thanks,
Ingo
Powered by blists - more mailing lists