From: Chih-En Lin <shiyn.lin@gmail.com>
To: David Hildenbrand <david@redhat.com>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>,
Andrew Morton <akpm@linux-foundation.org>,
Qi Zheng <zhengqi.arch@bytedance.com>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
John Hubbard <jhubbard@nvidia.com>, Nadav Amit <namit@vmware.com>,
Barry Song <baohua@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
Yang Shi <shy828301@gmail.com>, Peter Xu <peterx@redhat.com>,
Vlastimil Babka <vbabka@suse.cz>,
Zach O'Keefe <zokeefe@google.com>,
Yun Zhou <yun.zhou@windriver.com>,
Hugh Dickins <hughd@google.com>,
Suren Baghdasaryan <surenb@google.com>,
Yu Zhao <yuzhao@google.com>, Juergen Gross <jgross@suse.com>,
Tong Tiangen <tongtiangen@huawei.com>,
Liu Shixin <liushixin2@huawei.com>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Li kunyu <kunyu@nfschina.com>, Minchan Kim <minchan@kernel.org>,
Miaohe Lin <linmiaohe@huawei.com>,
Gautam Menghani <gautammenghani201@gmail.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Mark Brown <broonie@kernel.org>, Will Deacon <will@kernel.org>,
Vincenzo Frascino <Vincenzo.Frascino@arm.com>,
Thomas Gleixner <tglx@linutronix.de>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Andy Lutomirski <luto@kernel.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Fenghua Yu <fenghua.yu@intel.com>,
Andrei Vagin <avagin@gmail.com>, Barret Rhoden <brho@google.com>,
Michal Hocko <mhocko@suse.com>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
Alexey Gladkov <legion@kernel.org>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org,
linux-perf-users@vger.kernel.org,
Dinglan Peng <peng301@purdue.edu>,
Pedro Fonseca <pfonseca@purdue.edu>,
Jim Huang <jserv@ccns.ncku.edu.tw>,
Huichun Feng <foxhoundsk.tw@gmail.com>
Subject: Re: [PATCH v4 00/14] Introduce Copy-On-Write to Page Table
Date: Wed, 15 Feb 2023 01:56:30 +0800 [thread overview]
Message-ID: <Y+vLTmGLJP8pR1BG@strix-laptop> (raw)
In-Reply-To: <1bee97ef-7632-b1bf-f042-29b97882bfb6@redhat.com>
On Tue, Feb 14, 2023 at 06:03:58PM +0100, David Hildenbrand wrote:
> On 14.02.23 17:58, David Hildenbrand wrote:
> >
> > > > >
> > > > > Honestly, for improving the fork(), I have an idea to skip the per-page
> > > > > operation without breaking the logic. However, this will introduce the
> > > > > complicated mechanism and may has the overhead for other features. It
> > > > > might not be worth it. It's hard to strike a balance between the
> > > > > over-complicated mechanism with (probably) better performance and data
> > > > > consistency with the page status. So, I would focus on the safety and
> > > > > stable approach at first.
> > > >
> > > > Yes, it is most probably possible, but complexity, robustness and
> > > > maintainability have to be considered as well.
> > > >
> > > > Thanks for implementing this approach (only deduplication without other
> > > > optimizations) and evaluating it accordingly. It's certainly "cleaner", such
> > > > that we only have to mess with unsharing and not with other
> > > > accounting/pinning/mapcount thingies. But it also highlights how intrusive
> > > > even this basic deduplication approach already is -- and that most benefits
> > > > of the original approach requires even more complexity on top.
> > > >
> > > > I am not quite sure if the benefit is worth the price (I am not to decide
> > > > and I would like to hear other options).
> > >
> > > I'm looking at the discussion of page table sharing in 2002 [1].
> > > It looks like in 2002 ~ 2006, there also have some patches try to
> > > improve fork().
> > >
> > > After that, I also saw one thread which is about another shared page
> > > table patch's benchmark. I can't find the original patch though [2].
> > > But, I found the probably same patch in 2005 [3], it also mentioned
> > > the previous benchmark discussion:
> > >
> > > "
> > > For those familiar with the shared page table patch I did a couple of years
> > > ago, this patch does not implement copy-on-write page tables for private
> > > mappings. Analysis showed the cost and complexity far outweighed any
> > > potential benefit.
> > > "
> >
> > Thanks for the pointer, interesting read. And my personal opinion is
> > that part of that statement still hold true :)
> >
> > >
> > > However, it might be different right now. For example, the implemetation
> > > . We have split page table lock now, so we don't have to consider the
> > > page_table_share_lock thing. Also, presently, we have different use
> > > cases (shells [2] v.s. VM cloning and fuzzing) to consider.
>
>
> Oh, and because I stumbled over it, just as an interesting pointer on QEMU
> devel:
>
> "[PATCH 00/10] Retire Fork-Based Fuzzing" [1]
>
> [1] https://lore.kernel.org/all/20230205042951.3570008-1-alxndr@bu.edu/T/#u
Thanks for the information.
It's interesting.
Thanks,
Chih-En Lin
next prev parent reply other threads:[~2023-02-14 17:56 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-07 3:51 [PATCH v4 00/14] Introduce Copy-On-Write to Page Table Chih-En Lin
2023-02-07 3:51 ` [PATCH v4 01/14] mm: Allow user to control COW PTE via prctl Chih-En Lin
2023-02-07 3:51 ` [PATCH v4 02/14] mm: Add Copy-On-Write PTE to fork() Chih-En Lin
2023-02-07 3:51 ` [PATCH v4 03/14] mm: Add break COW PTE fault and helper functions Chih-En Lin
2023-02-07 3:51 ` [PATCH v4 04/14] mm/rmap: Break COW PTE in rmap walking Chih-En Lin
2023-02-07 3:51 ` [PATCH v4 05/14] mm/khugepaged: Break COW PTE before scanning pte Chih-En Lin
2023-02-07 3:51 ` [PATCH v4 06/14] mm/ksm: Break COW PTE before modify shared PTE Chih-En Lin
2023-02-07 3:51 ` [PATCH v4 07/14] mm/madvise: Handle COW-ed PTE with madvise() Chih-En Lin
2023-02-07 3:51 ` [PATCH v4 08/14] mm/gup: Trigger break COW PTE before calling follow_pfn_pte() Chih-En Lin
2023-02-07 3:51 ` [PATCH v4 09/14] mm/mprotect: Break COW PTE before changing protection Chih-En Lin
2023-02-07 3:51 ` [PATCH v4 10/14] mm/userfaultfd: Support COW PTE Chih-En Lin
2023-02-07 3:51 ` [PATCH v4 11/14] mm/migrate_device: " Chih-En Lin
2023-02-07 3:51 ` [PATCH v4 12/14] fs/proc: Support COW PTE with clear_refs_write Chih-En Lin
2023-02-07 3:51 ` [PATCH v4 13/14] events/uprobes: Break COW PTE before replacing page Chih-En Lin
2023-02-07 3:51 ` [PATCH v4 14/14] mm: fork: Enable COW PTE to fork system call Chih-En Lin
2023-02-09 18:15 ` [PATCH v4 00/14] Introduce Copy-On-Write to Page Table Pasha Tatashin
2023-02-10 2:17 ` Chih-En Lin
2023-02-10 16:21 ` Pasha Tatashin
2023-02-10 17:20 ` Chih-En Lin
2023-02-10 19:02 ` Chih-En Lin
2023-02-14 9:58 ` David Hildenbrand
2023-02-14 13:07 ` Pasha Tatashin
2023-02-14 13:17 ` David Hildenbrand
2023-02-14 15:59 ` Chih-En Lin
2023-02-14 16:30 ` Pasha Tatashin
2023-02-14 18:41 ` Chih-En Lin
2023-02-14 18:52 ` Pasha Tatashin
2023-02-14 19:17 ` Chih-En Lin
2023-02-14 16:58 ` David Hildenbrand
2023-02-14 17:03 ` David Hildenbrand
2023-02-14 17:56 ` Chih-En Lin [this message]
2023-02-14 17:54 ` Chih-En Lin
2023-02-14 17:59 ` David Hildenbrand
2023-02-14 19:06 ` Chih-En Lin
2023-02-14 17:23 ` Yang Shi
2023-02-14 17:39 ` David Hildenbrand
2023-02-14 18:25 ` Yang Shi
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=Y+vLTmGLJP8pR1BG@strix-laptop \
--to=shiyn.lin@gmail.com \
--cc=Jason@zx2c4.com \
--cc=Liam.Howlett@oracle.com \
--cc=Vincenzo.Frascino@arm.com \
--cc=acme@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=anshuman.khandual@arm.com \
--cc=avagin@gmail.com \
--cc=baohua@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=brho@google.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=david@redhat.com \
--cc=ebiederm@xmission.com \
--cc=fenghua.yu@intel.com \
--cc=foxhoundsk.tw@gmail.com \
--cc=gautammenghani201@gmail.com \
--cc=hughd@google.com \
--cc=jgross@suse.com \
--cc=jhubbard@nvidia.com \
--cc=jolsa@kernel.org \
--cc=jserv@ccns.ncku.edu.tw \
--cc=kunyu@nfschina.com \
--cc=legion@kernel.org \
--cc=linmiaohe@huawei.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=liushixin2@huawei.com \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=mhiramat@kernel.org \
--cc=mhocko@suse.com \
--cc=minchan@kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=namit@vmware.com \
--cc=pasha.tatashin@soleen.com \
--cc=peng301@purdue.edu \
--cc=peterx@redhat.com \
--cc=peterz@infradead.org \
--cc=pfonseca@purdue.edu \
--cc=rostedt@goodmis.org \
--cc=shy828301@gmail.com \
--cc=surenb@google.com \
--cc=tglx@linutronix.de \
--cc=tongtiangen@huawei.com \
--cc=vbabka@suse.cz \
--cc=will@kernel.org \
--cc=willy@infradead.org \
--cc=yun.zhou@windriver.com \
--cc=yuzhao@google.com \
--cc=zhengqi.arch@bytedance.com \
--cc=zokeefe@google.com \
/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.