linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Andrei Vagin <avagin@gmail.com>
Cc: kernel test robot <oliver.sang@intel.com>,
	Dmitry Safonov <0x7f454c46@gmail.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	lkp@lists.01.org, kernel test robot <lkp@intel.com>,
	Mike Rapoport <rppt@linux.ibm.com>
Subject: Re: [fs/pipe] 5a519c8fe4: WARNING:at_mm/page_alloc.c:#__alloc_pages
Date: Thu, 21 Apr 2022 12:28:20 -0700	[thread overview]
Message-ID: <CAHk-=wjdCtgtQPZPTigMMniZaoMA_tHDu3EMBVM3w1GH5X+cOw@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wgSW3gB1=rf3atv=3Xvn0pNBtKUKJ2VF81ue-xagS7F4w@mail.gmail.com>

On Thu, Apr 21, 2022 at 9:30 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> The pipe part sounds like a horrible hacky thing.
>
> I also assume you already tried that, and hit some performance issues.
> But it does sound like the better interface, more directly what you
> want.
>
> So what are the problems with using process_vm_readv?

Actually, I take that back.

Don't use pipes.

Don't use process_vm_readv().

Use the system call we already have for "snapshot the current VM".

It's called "fork()". It's cheap, it's efficient, and it snapshots the
whole VM in one go. No stupid extra buffers in pipes, no crazy things
like that.

So just make your pre-dump code do a simple fork(), let the parent
continue, and then do the dumping in the child at whatever pace you
want.

In fact, you might just leave the child process alone, and let it _be_
that pre-dump.

You can create a new snapshot every once in a while, and kill the
previous snapshot, if you want to keep the snapshot close to the
target, and then use the memory tracking to track what has changed
since.

And you might not want to use plain "fork()", but instead some kind of
"clone()" variant. You might want to use CLONE_PARENT and some
non-SIGCHLD exit signal to basically hide the snapshot image from the
thing you are snapshotting.

Anyway, the "use vmsplice to a pipe to create a snapshot" sounds just
insane when you have a very traditional system call that is all about
snapshotting the process.

Maybe a new CLONE_xyz flag could be added to make that memory tracking
integrate better or whatever.

Any showstoppers?

                         Linus

  reply	other threads:[~2022-04-21 19:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-20  7:37 [fs/pipe] 5a519c8fe4: WARNING:at_mm/page_alloc.c:#__alloc_pages kernel test robot
2022-04-20 19:07 ` Linus Torvalds
2022-04-21 15:35   ` Andrei Vagin
2022-04-21 16:30     ` Linus Torvalds
2022-04-21 19:28       ` Linus Torvalds [this message]
2022-04-22  5:23         ` Andrei Vagin
2022-04-22 17:23           ` Linus Torvalds
2022-04-23 20:23             ` Andrei Vagin
2022-04-23 21:02               ` Linus Torvalds

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='CAHk-=wjdCtgtQPZPTigMMniZaoMA_tHDu3EMBVM3w1GH5X+cOw@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=0x7f454c46@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=avagin@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=lkp@lists.01.org \
    --cc=oliver.sang@intel.com \
    --cc=rppt@linux.ibm.com \
    --cc=viro@zeniv.linux.org.uk \
    /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;
as well as URLs for NNTP newsgroup(s).