All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brendan Jackman <jackmanb@google.com>
To: Brendan Jackman <jackmanb@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	 Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	 Dave Hansen <dave.hansen@linux.intel.com>, <x86@kernel.org>,
	 Andrew Morton <akpm@linux-foundation.org>,
	David Rientjes <rientjes@google.com>,
	 Vlastimil Babka <vbabka@suse.cz>,
	David Hildenbrand <david@redhat.com>
Cc: <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
	 Mike Rapoport <rppt@kernel.org>,
	Junaid Shahid <junaids@google.com>,
	 Reiji Watanabe <reijiw@google.com>,
	Patrick Bellasi <derkling@google.com>,
	 Yosry Ahmed <yosry.ahmed@linux.dev>
Subject: Re: [PATCH RFC 00/11] mm: ASI integration for the page allocator
Date: Tue, 10 Jun 2025 17:04:46 +0000	[thread overview]
Message-ID: <DAJ0LUX8F2IW.Q95PTFBNMFOI@google.com> (raw)
In-Reply-To: <20250313-asi-page-alloc-v1-0-04972e046cea@google.com>

On Thu Mar 13, 2025 at 6:11 PM UTC, Brendan Jackman wrote:
> .:: Patchset overview

Hey all, I have been down the pagetable mines lately trying to figure
out a solution to the page cache issue (the 70% FIO degradatation [0]).
I've got a prototype based on the idea I discussed at LSF/MM/BPF
that's slowly coming together. My hope is that as soon as I can
convincingly claim with a straight face that I know how to solve that
problem, I can transition from <post an RFC every N months then
disappear> mode into being a bit more visible with development
iterations...

[0] https://lore.kernel.org/linux-mm/20250129144320.2675822-1-jackmanb@google.com/

In the meantime, I am still provisionally planning to make the topic
of this RFC the first [PATCH] series for ASI. Obviously before I can
seriously ask Andrew to merge I'll also need to establish some
consensus on the x86 side, but in the meantime I think we're getting
close enough to start discussing the mm code.

So.. does anyone have a bit of time to look over this and see if the
implementation makes sense? Is the basic idea on the right lines?
Also if there's anything I can do to make that easier (is it worth
rebasing?) let me know.

Also, I guess I should also note my aspirational plan for the next few
months, it goes...

1. Get a convincing PoC working that improves the FIO degradation.

2. Gather it into a fairly messy but at least surveyable branch and push
   that to Github or whatever.

3. Show that to x86 folks and hopefully (!!) get some maintainers to
   give a nod like "yep we want ASI and we're more or less sold that
   the developers know how to make it performant".

4. Turn this [RFC] into a [PATCH]. So start by trying to merge the stuff
   that manages the restricted address space, leaving the logic of actually
   _using_ it for a later series.

5. [Maybe this can be partially paralellised with 4] start a new [PATCH]
   series that starts adding in the x86 stuff to actually switch address
   spaces etc. Basically this means respinning the patches that Boris
   has reviewed in [1]. Since we already have the page_alloc stuff, it
   should be possible to start testing this code end-to-end quickly.

[1] https://lore.kernel.org/linux-mm/20250110-asi-rfc-v2-v2-0-8419288bc805@google.com/

Anyone have any thoughts on that overall strategy?

Cheers,
Brendan



      parent reply	other threads:[~2025-06-10 17:04 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-13 18:11 [PATCH RFC 00/11] mm: ASI integration for the page allocator Brendan Jackman
2025-03-13 18:11 ` [PATCH RFC 01/11] x86/mm: Bare minimum ASI API for page_alloc integration Brendan Jackman
2025-03-13 18:11 ` [PATCH RFC 02/11] x86/mm: Factor out phys_pgd_init() Brendan Jackman
2025-03-13 22:14   ` Yosry Ahmed
2025-03-17 16:24     ` Brendan Jackman
2025-03-13 18:11 ` [PATCH RFC 03/11] x86/mm: Add lookup_pgtable_in_pgd() Brendan Jackman
2025-03-13 22:09   ` Yosry Ahmed
2025-03-14  9:12     ` Brendan Jackman
2025-03-14 17:56       ` Yosry Ahmed
2025-03-13 18:11 ` [PATCH RFC 04/11] x86/mm/asi: Sync physmap into ASI_GLOBAL_NONSENSITIVE Brendan Jackman
2025-03-13 18:11 ` [PATCH RFC HACKS 05/11] Add asi_map() and asi_unmap() Brendan Jackman
2025-03-13 18:11 ` [PATCH RFC 06/11] mm/page_alloc: Add __GFP_SENSITIVE and always set it Brendan Jackman
2025-03-13 18:11 ` [PATCH RFC HACKS 07/11] mm/slub: Set __GFP_SENSITIVE for reclaimable slabs Brendan Jackman
2025-03-13 18:11 ` [PATCH RFC HACKS 08/11] mm/page_alloc: Simplify gfp_migratetype() Brendan Jackman
2025-03-13 18:11 ` [PATCH RFC 09/11] mm/page_alloc: Split MIGRATE_UNMOVABLE by sensitivity Brendan Jackman
2025-03-13 18:11 ` [PATCH RFC 10/11] mm/page_alloc: Add support for nonsensitive allocations Brendan Jackman
2025-03-13 18:11 ` [PATCH RFC 11/11] mm/page_alloc: Add support for ASI-unmapping pages Brendan Jackman
2025-06-10 17:04 ` Brendan Jackman [this message]

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=DAJ0LUX8F2IW.Q95PTFBNMFOI@google.com \
    --to=jackmanb@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@redhat.com \
    --cc=derkling@google.com \
    --cc=junaids@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@redhat.com \
    --cc=reijiw@google.com \
    --cc=rientjes@google.com \
    --cc=rppt@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=vbabka@suse.cz \
    --cc=x86@kernel.org \
    --cc=yosry.ahmed@linux.dev \
    /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.