From: Michel Lespinasse <michel@lespinasse.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Michel Lespinasse <michel@lespinasse.org>,
Linux-MM <linux-mm@kvack.org>,
Laurent Dufour <ldufour@linux.ibm.com>,
Michal Hocko <mhocko@suse.com>,
Matthew Wilcox <willy@infradead.org>,
Rik van Riel <riel@surriel.com>,
Paul McKenney <paulmck@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Suren Baghdasaryan <surenb@google.com>,
Joel Fernandes <joelaf@google.com>,
Rom Lemarchand <romlem@google.com>,
Linux-Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 11/37] x86/mm: attempt speculative mm faults first
Date: Wed, 7 Apr 2021 13:14:53 -0700 [thread overview]
Message-ID: <20210407201453.GA25738@lespinasse.org> (raw)
In-Reply-To: <YG3GTI8j1ohk4NhS@hirez.programming.kicks-ass.net>
On Wed, Apr 07, 2021 at 04:48:44PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 06, 2021 at 06:44:36PM -0700, Michel Lespinasse wrote:
> > --- a/arch/x86/mm/fault.c
> > +++ b/arch/x86/mm/fault.c
> > @@ -1219,6 +1219,8 @@ void do_user_addr_fault(struct pt_regs *regs,
> > struct mm_struct *mm;
> > vm_fault_t fault;
> > unsigned int flags = FAULT_FLAG_DEFAULT;
> > + struct vm_area_struct pvma;
>
> That's 200 bytes on-stack... I suppose that's just about acceptible, but
> perhaps we need a comment in struct vm_area_struct to make people aware
> this things lives on-stack and size really is an issue now.
Right, I agree that having the vma copy on-stack is not ideal.
I think what really should be done, is to copy just the attributes of
the vma that will be needed during the page fault. Things like vm_mm,
vm_page_prot, vm_flags, vm_ops, vm_pgoff, vm_file, vm_private_data,
vm_policy. We definitely do not need rbtree and rmap fields such as
vm_prev, vm_next, vm_rb, rb_subtree_gap, shared, anon_vma_chain etc...
The reason I did things this way, is because changing the entire fault
handler to use attributes stored in struct vm_fault, rather than in
the original vma, would be quite intrusive. I think it would be a
reasonable step to consider once there is agreement on the rest of the
speculative fault patch set, but it's practical doing it before then.
next prev parent reply other threads:[~2021-04-07 20:14 UTC|newest]
Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-07 1:44 [RFC PATCH 00/37] Speculative page faults Michel Lespinasse
2021-04-07 1:44 ` [RFC PATCH 01/37] mmap locking API: mmap_lock_is_contended returns a bool Michel Lespinasse
2021-04-07 1:44 ` [RFC PATCH 02/37] mmap locking API: name the return values Michel Lespinasse
2021-04-07 1:44 ` [RFC PATCH 03/37] do_anonymous_page: use update_mmu_tlb() Michel Lespinasse
2021-04-07 2:06 ` Michel Lespinasse
2021-04-07 1:44 ` [RFC PATCH 04/37] do_anonymous_page: reduce code duplication Michel Lespinasse
2021-04-07 1:44 ` [RFC PATCH 05/37] mm: introduce CONFIG_SPECULATIVE_PAGE_FAULT Michel Lespinasse
2021-04-07 1:44 ` [RFC PATCH 06/37] x86/mm: define ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT Michel Lespinasse
2021-04-07 1:44 ` [RFC PATCH 07/37] mm: add FAULT_FLAG_SPECULATIVE flag Michel Lespinasse
2021-04-07 1:44 ` [RFC PATCH 08/37] mm: add do_handle_mm_fault() Michel Lespinasse
2021-04-07 1:44 ` [RFC PATCH 09/37] mm: add per-mm mmap sequence counter for speculative page fault handling Michel Lespinasse
2021-04-07 12:48 ` kernel test robot
2021-04-07 14:47 ` Peter Zijlstra
2021-04-07 20:50 ` Michel Lespinasse
2021-04-07 1:44 ` [RFC PATCH 10/37] mm: rcu safe vma freeing Michel Lespinasse
2021-04-07 1:44 ` [RFC PATCH 11/37] x86/mm: attempt speculative mm faults first Michel Lespinasse
2021-04-07 14:48 ` Peter Zijlstra
2021-04-07 15:35 ` Matthew Wilcox
2021-04-07 20:32 ` Michel Lespinasse
2021-04-07 20:14 ` Michel Lespinasse [this message]
2021-04-07 20:18 ` Michel Lespinasse
2021-04-07 1:44 ` [RFC PATCH 12/37] mm: refactor __handle_mm_fault() / handle_pte_fault() Michel Lespinasse
2021-04-07 1:44 ` [RFC PATCH 13/37] mm: implement speculative handling in __handle_mm_fault() Michel Lespinasse
2021-04-07 15:36 ` Andy Lutomirski
2021-04-28 14:58 ` Michel Lespinasse
2021-04-28 15:13 ` Andy Lutomirski
2021-04-28 16:11 ` Paul E. McKenney
2021-04-29 0:02 ` Michel Lespinasse
2021-04-29 0:05 ` Andy Lutomirski
2021-04-29 16:12 ` Matthew Wilcox
2021-04-29 18:04 ` Andy Lutomirski
2021-04-29 19:14 ` Michel Lespinasse
2021-04-29 19:34 ` Matthew Wilcox
2021-04-29 23:56 ` Michel Lespinasse
2021-04-29 15:52 ` Paul E. McKenney
2021-04-29 18:34 ` Paul E. McKenney
2021-04-29 18:49 ` Matthew Wilcox
2021-05-03 3:14 ` Paul E. McKenney
2021-04-29 21:17 ` Michel Lespinasse
2021-05-03 3:40 ` Paul E. McKenney
2021-05-03 4:34 ` Michel Lespinasse
2021-05-03 16:32 ` Paul E. McKenney
2021-04-07 1:44 ` [RFC PATCH 14/37] mm: add pte_map_lock() and pte_spinlock() Michel Lespinasse
2021-04-07 4:21 ` kernel test robot
2021-04-07 5:08 ` kernel test robot
2021-04-07 1:44 ` [RFC PATCH 15/37] mm: implement speculative handling in do_anonymous_page() Michel Lespinasse
2021-04-07 1:44 ` [RFC PATCH 16/37] mm: enable speculative fault handling through do_anonymous_page() Michel Lespinasse
2021-04-07 1:44 ` [RFC PATCH 17/37] mm: implement speculative handling in do_numa_page() Michel Lespinasse
2021-04-07 1:44 ` [RFC PATCH 18/37] mm: enable speculative fault " Michel Lespinasse
2021-04-07 1:44 ` [RFC PATCH 19/37] mm: implement speculative handling in wp_page_copy() Michel Lespinasse
2021-04-07 1:44 ` [RFC PATCH 20/37] mm: implement and enable speculative fault handling in handle_pte_fault() Michel Lespinasse
2021-04-07 1:44 ` [RFC PATCH 21/37] mm: implement speculative handling in do_swap_page() Michel Lespinasse
2021-04-07 1:44 ` [RFC PATCH 22/37] mm: enable speculative fault handling through do_swap_page() Michel Lespinasse
2021-04-07 1:44 ` [RFC PATCH 23/37] mm: rcu safe vma->vm_file freeing Michel Lespinasse
2021-04-08 5:12 ` [mm] 87b1c39af4: nvml.blk_rw_mt_TEST0_check_pmem_debug.fail kernel test robot
2021-04-08 5:12 ` kernel test robot
2021-04-07 1:44 ` [RFC PATCH 24/37] mm: implement speculative handling in __do_fault() Michel Lespinasse
2021-04-07 2:35 ` Matthew Wilcox
2021-04-07 2:53 ` Michel Lespinasse
2021-04-07 3:01 ` Matthew Wilcox
2021-04-07 14:40 ` Peter Zijlstra
2021-04-07 21:20 ` Michel Lespinasse
2021-04-07 21:27 ` Matthew Wilcox
2021-04-08 7:00 ` Peter Zijlstra
2021-04-08 7:13 ` Matthew Wilcox
2021-04-08 8:18 ` Peter Zijlstra
2021-04-08 8:37 ` Michel Lespinasse
2021-04-08 11:28 ` Matthew Wilcox
2021-04-07 1:44 ` [RFC PATCH 25/37] mm: implement speculative handling in filemap_fault() Michel Lespinasse
2021-04-07 1:44 ` [RFC PATCH 26/37] mm: implement speculative fault handling in finish_fault() Michel Lespinasse
2021-04-07 1:44 ` [RFC PATCH 27/37] mm: implement speculative handling in do_fault_around() Michel Lespinasse
2021-04-07 2:37 ` Matthew Wilcox
2021-04-07 1:44 ` [RFC PATCH 28/37] mm: implement speculative handling in filemap_map_pages() Michel Lespinasse
2021-04-07 1:44 ` [RFC PATCH 29/37] fs: list file types that support speculative faults Michel Lespinasse
2021-04-07 2:39 ` Matthew Wilcox
2021-04-07 1:44 ` [RFC PATCH 30/37] mm: enable speculative fault handling for supported file types Michel Lespinasse
2021-04-07 1:44 ` [RFC PATCH 31/37] ext4: implement speculative fault handling Michel Lespinasse
2021-04-07 1:44 ` [RFC PATCH 32/37] f2fs: " Michel Lespinasse
2021-04-07 1:44 ` [RFC PATCH 33/37] mm: enable speculative fault handling only for multithreaded user space Michel Lespinasse
2021-04-07 2:48 ` Matthew Wilcox
2021-04-07 1:44 ` [RFC PATCH 34/37] mm: rcu safe vma freeing " Michel Lespinasse
2021-04-07 2:50 ` Matthew Wilcox
2021-04-08 7:53 ` Michel Lespinasse
2021-04-07 1:45 ` [RFC PATCH 35/37] mm: spf statistics Michel Lespinasse
2021-04-07 5:08 ` kernel test robot
2021-04-07 12:48 ` kernel test robot
2021-04-07 1:45 ` [RFC PATCH 36/37] arm64/mm: define ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT Michel Lespinasse
2021-04-07 1:45 ` [RFC PATCH 37/37] arm64/mm: attempt speculative mm faults first Michel Lespinasse
2021-04-21 1:44 ` [RFC PATCH 00/37] Speculative page faults Chinwen Chang
2021-06-28 22:14 ` Axel Rasmussen
2021-07-21 11:33 ` vjitta
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=20210407201453.GA25738@lespinasse.org \
--to=michel@lespinasse.org \
--cc=akpm@linux-foundation.org \
--cc=joelaf@google.com \
--cc=ldufour@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=riel@surriel.com \
--cc=romlem@google.com \
--cc=surenb@google.com \
--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 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.