All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manfred Spraul <manfred@colorfullife.com>
To: Eli Cohen <mlxk@mellanox.co.il>
Cc: Roland Dreier <roland@topspin.com>, linux-kernel@vger.kernel.org
Subject: Re: locking user space memory in kernel
Date: Mon, 22 Mar 2004 20:34:13 +0100	[thread overview]
Message-ID: <405F3FB5.4020001@colorfullife.com> (raw)
In-Reply-To: <405F04B5.2090609@mellanox.co.il>

Eli Cohen wrote:

> Roland Dreier wrote:
>
>> I don't think copying all the registered memory on fork() is feasible,
>> because it's going to kill performance (especially since exec() is
>> likely to immediately follow the fork() in the child).  Also, there
>> may not be enough memory around to copy everything.
>>
>>  
>>
> Suppose a new vma flag is introduced, VM_NOCOW and an API to apply 
> this flag on a range of addreses, splitting or unifying vmas as necessary.

Something like that. But it should be hidden within a suitable 
abstraction. get_user_pages and then put_page is not stateful enough. 
Actually it's fundamentally broken for platform that need cache flush 
calls. create_page_mapping/free_page_mapping, or something like that.

And I still think that the initial implementation should copy the 
affected pages within fork() - it might be slow, but at least it's 
simple and correct. _If_ it's too slow, then it can be fixed later.

--
    Manfred




  reply	other threads:[~2004-03-22 19:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-21 11:31 locking user space memory in kernel Manfred Spraul
2004-03-21 14:12 ` Manfred Spraul
2004-03-21 16:40 ` Roland Dreier
2004-03-21 17:15   ` Manfred Spraul
2004-03-21 18:18     ` Roland Dreier
2004-03-22 13:15       ` Eli Cohen
2004-03-22 15:22       ` Eli Cohen
2004-03-22 19:34         ` Manfred Spraul [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-04-08  6:20 Ross Dickson
2004-04-08  0:45 Libor Michalek
2004-04-08  5:22 ` Manfred Spraul
2004-03-21 11:18 Eli Cohen
2004-03-21 11:35 ` Arjan van de Ven

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=405F3FB5.4020001@colorfullife.com \
    --to=manfred@colorfullife.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mlxk@mellanox.co.il \
    --cc=roland@topspin.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.