All of lore.kernel.org
 help / color / mirror / Atom feed
From: glebn@voltaire.com (Gleb Natapov)
To: Bill Jordan <woodennickel@gmail.com>
Cc: Hugh Dickins <hugh@veritas.com>,
	"Michael S. Tsirkin" <mst@mellanox.co.il>,
	Roland Dreier <roland@topspin.com>,
	linux-kernel@vger.kernel.org, openib-general@openib.org
Subject: Re: [openib-general] Re: [PATCH repost] PROT_DONTCOPY: ifiniband uverbs fork support
Date: Tue, 16 Aug 2005 10:52:17 +0300	[thread overview]
Message-ID: <20050816075217.GA6232@minantech.com> (raw)
In-Reply-To: <5ebee0d10508150937da6c1ed@mail.gmail.com>

On Mon, Aug 15, 2005 at 12:37:50PM -0400, Bill Jordan wrote:
> On 8/11/05, Gleb Natapov <glebn@voltaire.com> wrote:
> > What about the idea that was floating around about new VM flag that will
> > instruct kernel to copy pages belonging to the vma on fork instead of mark
> > them as cow?
> > 
> 
> I think the big problem with this idea is the huge memory regions that
> InfiniBand applications are dealing with. If the application forks (or
> uses system()), you are going to copy a huge chunk of data (most
> likely swapping since the application memory footprint is probably
> already tuned to consume the available physical memory). And the copy
> is really for nothing since in most (or at least many) cases the child
> is just going to exec anyway.
If the child is going to exec it may call vfork or clone with CLONE_VM
flag. glibc system(3) does clone (CLONE_PARENT_SETTID | SIGCHLD) why not
CLONE_VM too? This single change will allow to use system() from MPI
programs thus eliminating many users problem. 
If the child isn't going to exec it should face the music.

--
			Gleb.

      reply	other threads:[~2005-08-16  7:52 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-19 16:55 [PATCH] fork support Michael S. Tsirkin
2005-07-25 17:19 ` [PATCH repost] PROT_DONTCOPY: ifiniband uverbs " Michael S. Tsirkin
2005-07-26 12:30   ` Hugh Dickins
2005-07-26 13:35     ` Michael S. Tsirkin
2005-08-09 18:13       ` Hugh Dickins
2005-08-10  8:30         ` Michael S. Tsirkin
2005-08-10  8:39         ` [openib-general] " Gleb Natapov
2005-08-10 13:22           ` Hugh Dickins
2005-08-10 13:26             ` Gleb Natapov
2005-08-10 15:27               ` Hugh Dickins
2005-08-11  8:02                 ` Gleb Natapov
2005-08-11 14:04                   ` Hugh Dickins
2005-08-11 14:07                     ` Gleb Natapov
2005-08-11 14:17                       ` Hugh Dickins
2005-08-11 14:11                     ` Michael S. Tsirkin
2005-08-15 16:37                   ` Bill Jordan
2005-08-16  7:52                     ` Gleb Natapov [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=20050816075217.GA6232@minantech.com \
    --to=glebn@voltaire.com \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@mellanox.co.il \
    --cc=openib-general@openib.org \
    --cc=roland@topspin.com \
    --cc=woodennickel@gmail.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.