linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Yu Zhao <yuzhao@google.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>,
	 Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	 Vincent Guittot <vincent.guittot@linaro.org>
Cc: Alexander Potapenko <glider@google.com>,
	Marco Elver <elver@google.com>,
	 Alexander Viro <viro@zeniv.linux.org.uk>,
	Alexei Starovoitov <ast@kernel.org>,
	 Andrey Konovalov <andreyknvl@google.com>,
	Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
	 Borislav Petkov <bp@alien8.de>, Christoph Hellwig <hch@lst.de>,
	Christoph Lameter <cl@linux.com>,
	 David Rientjes <rientjes@google.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	 Eric Dumazet <edumazet@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	 Herbert Xu <herbert@gondor.apana.org.au>,
	Ilya Leoshkevich <iii@linux.ibm.com>,
	 Jens Axboe <axboe@kernel.dk>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	 Kees Cook <keescook@chromium.org>,
	Mark Rutland <mark.rutland@arm.com>,
	 Matthew Wilcox <willy@infradead.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Pekka Enberg <penberg@kernel.org>,
	 Petr Mladek <pmladek@suse.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	 Thomas Gleixner <tglx@linutronix.de>,
	Vasily Gorbik <gor@linux.ibm.com>,
	 Vegard Nossum <vegard.nossum@oracle.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	 kasan-dev <kasan-dev@googlegroups.com>,
	 Linux Memory Management List <linux-mm@kvack.org>,
	Linux-Arch <linux-arch@vger.kernel.org>,
	 LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v5 04/44] x86: asm: instrument usercopy in get_user() and put_user()
Date: Thu, 1 Sep 2022 17:44:03 -0600	[thread overview]
Message-ID: <CAOUHufY91Eju-g1+xbUsGkGZ-cwBm78v+S_Air7Cp8mAnYJVYA@mail.gmail.com> (raw)
In-Reply-To: <20220830150549.afa67340c2f5eb33ff9615f4@linux-foundation.org>

On Tue, Aug 30, 2022 at 4:05 PM Andrew Morton <akpm@linux-foundation.org> wrote:
...
> Yu, that inclusion is regrettable.  I don't think mm_types.h is an
> appropriate site for implementing lru_gen_use_mm() anyway.  Adding a
> new header is always the right fix for these things.  I'd suggest
> adding a new mglru.h (or whatever) and putting most/all of the mglru
> material in there.
>
> Also, the addition to kernel/sched/core.c wasn't clearly changelogged,
> is uncommented and I doubt if the sched developers know about it, let
> alone reviewed it.  Please give them a heads-up.

Adding Ingo, Peter, Juri and Vincent.

I added lru_gen_use_mm() (one store operation) to context_switch() in
kernel/sched/core.c, and I would appreciate it if you could take a
look and let me know if you have any concerns:
https://lore.kernel.org/r/20220815071332.627393-9-yuzhao@google.com/

I'll resend the series in a week or so, and cc you when that happens.

> The addition looks fairly benign, but core context_switch() is the
> sort of thing which people get rather defensive about and putting
> mm-specific stuff in there might be challenged.  Some quantitative
> justification of this optimization would be appropriate.

The commit message (from the above link) touches on the theory only:

    This patch uses the following optimizations when walking page tables:
    1. It tracks the usage of mm_struct's between context switches so that
       page table walkers can skip processes that have been sleeping since
       the last iteration.

Let me expand on this.

TLDR: lru_gen_use_mm() introduces an extra store operation whenever
switching to a new mm_struct, which sets a flag for page reclaim to
clear.

For systems that are NOT under memory pressure:
1. This is a new overhead.
2. I don't think it's measurable, hence can't be the last straw.
3. Assume it can be measured, the belief is that underutilized systems
should be sacrificed (to some degree) for the greater good.

For systems that are under memory pressure:
1. When this flag is set on a mm_struct, page reclaim knows that this
mm_struct has been used since the last time it cleared this flag. So
it's worth checking out this mm_struct (to clear the accessed bit).
2. The similar idea has been used on Android and ChromeOS: when an app
or a tab goes to the background, these systems (conditionally) call
MADV_COLD. The majority of GUI applications don't implement this idea.
MGLRU opts to do it for the benefit of them. How it benefits server
applications is unknown (uninteresting).
3. This optimization benefits arm64 v8.2+ more than x86, since x86
supports the accessed bit in non-leaf entries and therefore the search
space can be reduced based on that. On a 4GB ARM system with 40 Chrome
tabs opened and 5 tabs in active use, this optimization improves page
table walk performance by about 5%. The overall benefit is small but
measurable under heavy memory pressure.
4. The idea can be reused by other MM components, e.g., khugepaged.

Thanks.


  parent reply	other threads:[~2022-09-01 23:44 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-26 15:07 [PATCH v5 00/44] Add KernelMemorySanitizer infrastructure Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 01/44] x86: add missing include to sparsemem.h Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 02/44] stackdepot: reserve 5 extra bits in depot_stack_handle_t Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 03/44] instrumented.h: allow instrumenting both sides of copy_from_user() Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 04/44] x86: asm: instrument usercopy in get_user() and put_user() Alexander Potapenko
2022-08-27  4:17   ` Andrew Morton
2022-08-29 14:57     ` Alexander Potapenko
2022-08-29 19:24       ` Andrew Morton
2022-08-30 14:23         ` Alexander Potapenko
2022-08-30 22:05           ` Andrew Morton
2022-08-30 22:25             ` Yu Zhao
2022-08-30 23:00               ` Andrew Morton
2022-08-30 23:07                 ` Yu Zhao
2022-08-31  7:13                   ` Alexander Potapenko
2022-09-01 23:44             ` Yu Zhao [this message]
2022-08-30 15:06   ` Christophe Leroy
2022-08-30 15:21     ` Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 05/44] asm-generic: instrument usercopy in cacheflush.h Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 06/44] kmsan: add ReST documentation Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 07/44] kmsan: introduce __no_sanitize_memory and __no_kmsan_checks Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 08/44] kmsan: mark noinstr as __no_sanitize_memory Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 09/44] x86: kmsan: pgtable: reduce vmalloc space Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 10/44] libnvdimm/pfn_dev: increase MAX_STRUCT_PAGE_SIZE Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 11/44] kmsan: add KMSAN runtime core Alexander Potapenko
2022-08-27  4:00   ` Andrew Morton
2022-08-26 15:07 ` [PATCH v5 12/44] kmsan: disable instrumentation of unsupported common kernel code Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 13/44] MAINTAINERS: add entry for KMSAN Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 14/44] mm: kmsan: maintain KMSAN metadata for page operations Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 15/44] mm: kmsan: call KMSAN hooks from SLUB code Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 16/44] kmsan: handle task creation and exiting Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 17/44] init: kmsan: call KMSAN initialization routines Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 18/44] instrumented.h: add KMSAN support Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 19/44] kmsan: unpoison @tlb in arch_tlb_gather_mmu() Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 20/44] kmsan: add iomap support Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 21/44] Input: libps2: mark data received in __ps2_command() as initialized Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 22/44] dma: kmsan: unpoison DMA mappings Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 23/44] virtio: kmsan: check/unpoison scatterlist in vring_map_one_sg() Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 24/44] kmsan: handle memory sent to/from USB Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 25/44] kmsan: add tests for KMSAN Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 26/44] kmsan: disable strscpy() optimization under KMSAN Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 27/44] crypto: kmsan: disable accelerated configs " Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 28/44] kmsan: disable physical page merging in biovec Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 29/44] block: kmsan: skip bio block merging logic for KMSAN Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 30/44] kcov: kmsan: unpoison area->list in kcov_remote_area_put() Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 31/44] security: kmsan: fix interoperability with auto-initialization Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 32/44] objtool: kmsan: list KMSAN API functions as uaccess-safe Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 33/44] x86: kmsan: disable instrumentation of unsupported code Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 34/44] x86: kmsan: skip shadow checks in __switch_to() Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 35/44] x86: kmsan: handle open-coded assembly in lib/iomem.c Alexander Potapenko
2022-08-26 15:07 ` [PATCH v5 36/44] x86: kmsan: use __msan_ string functions where possible Alexander Potapenko
2022-08-26 15:08 ` [PATCH v5 37/44] x86: kmsan: sync metadata pages on page fault Alexander Potapenko
2022-08-26 15:08 ` [PATCH v5 38/44] x86: kasan: kmsan: support CONFIG_GENERIC_CSUM on x86, enable it for KASAN/KMSAN Alexander Potapenko
2022-08-26 15:08 ` [PATCH v5 39/44] x86: fs: kmsan: disable CONFIG_DCACHE_WORD_ACCESS Alexander Potapenko
2022-08-26 15:08 ` [PATCH v5 40/44] x86: kmsan: don't instrument stack walking functions Alexander Potapenko
2022-08-26 15:08 ` [PATCH v5 41/44] entry: kmsan: introduce kmsan_unpoison_entry_regs() Alexander Potapenko
2022-08-26 15:08 ` [PATCH v5 42/44] bpf: kmsan: initialize BPF registers with zeroes Alexander Potapenko
2022-08-26 15:08 ` [PATCH v5 43/44] mm: fs: initialize fsdata passed to write_begin/write_end interface Alexander Potapenko
2022-08-26 15:08 ` [PATCH v5 44/44] x86: kmsan: enable KMSAN builds for x86 Alexander Potapenko

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=CAOUHufY91Eju-g1+xbUsGkGZ-cwBm78v+S_Air7Cp8mAnYJVYA@mail.gmail.com \
    --to=yuzhao@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@google.com \
    --cc=arnd@arndb.de \
    --cc=ast@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=bp@alien8.de \
    --cc=cl@linux.com \
    --cc=dvyukov@google.com \
    --cc=edumazet@google.com \
    --cc=elver@google.com \
    --cc=glider@google.com \
    --cc=gor@linux.ibm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=herbert@gondor.apana.org.au \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=iii@linux.ibm.com \
    --cc=juri.lelli@redhat.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=keescook@chromium.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=mst@redhat.com \
    --cc=penberg@kernel.org \
    --cc=peterz@infradead.org \
    --cc=pmladek@suse.com \
    --cc=rientjes@google.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=vbabka@suse.cz \
    --cc=vegard.nossum@oracle.com \
    --cc=vincent.guittot@linaro.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox