From: Roland Dreier <rdreier@cisco.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Eli Cohen <eli@mellanox.co.il>,
Andrew Morton <akpm@linux-foundation.org>,
Rusty Russell <rusty@rustcorp.com.au>,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org
Subject: Re: FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT
Date: Wed, 04 Feb 2009 21:33:34 -0800 [thread overview]
Message-ID: <adawsc5jvm9.fsf@cisco.com> (raw)
In-Reply-To: <1233811493.4612.69.camel@pasglop> (Benjamin Herrenschmidt's message of "Thu, 05 Feb 2009 16:24:53 +1100")
> Right, but then you need to set that in the VMA's, and thus gone is your
> nice fast g_u_p() that doesn't touch VMAs :-)
Registering memory is a slow path thing in the RDMA world. Speeding it
up is nice, so we make userspace do the madvise(VM_DONTCOPY) if it cares
but if it doesn't it can leave it out.
> > Yes, but unfortunately MPI says apps can allocate memory however they
> > damn well please... in any case these issues are all-too-well-known in
> > the RDMA world for quite a while.
> Yup. What do you think of the idea of pre-COWing pages with an elevated
> count at fork time ?
Super-duper sucks if the first thing the child does is exec() :)
Also if the parent has registered > half the memory in the system then
it's instant OOM. So not that useful for the RDMA case :)
The one thing that might make sense is to pre-COW any partial pages that
the parent has registered -- ie if half a page can be used by the child,
at least pre-COW that, but leave all the full pages with VM_DONTCOPY.
- R.
WARNING: multiple messages have this Message-ID (diff)
From: Roland Dreier <rdreier@cisco.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Eli Cohen <eli@mellanox.co.il>,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT
Date: Wed, 04 Feb 2009 21:33:34 -0800 [thread overview]
Message-ID: <adawsc5jvm9.fsf@cisco.com> (raw)
In-Reply-To: <1233811493.4612.69.camel@pasglop> (Benjamin Herrenschmidt's message of "Thu, 05 Feb 2009 16:24:53 +1100")
> Right, but then you need to set that in the VMA's, and thus gone is your
> nice fast g_u_p() that doesn't touch VMAs :-)
Registering memory is a slow path thing in the RDMA world. Speeding it
up is nice, so we make userspace do the madvise(VM_DONTCOPY) if it cares
but if it doesn't it can leave it out.
> > Yes, but unfortunately MPI says apps can allocate memory however they
> > damn well please... in any case these issues are all-too-well-known in
> > the RDMA world for quite a while.
> Yup. What do you think of the idea of pre-COWing pages with an elevated
> count at fork time ?
Super-duper sucks if the first thing the child does is exec() :)
Also if the parent has registered > half the memory in the system then
it's instant OOM. So not that useful for the RDMA case :)
The one thing that might make sense is to pre-COW any partial pages that
the parent has registered -- ie if half a page can be used by the child,
at least pre-COW that, but leave all the full pages with VM_DONTCOPY.
- R.
next prev parent reply other threads:[~2009-02-05 5:33 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-03 16:49 [PATCH] powerpc/mm: Export HPAGE_SHIFT Eli Cohen
2009-02-04 1:08 ` FW: " Roland Dreier
2009-02-04 1:08 ` Roland Dreier
2009-02-04 1:50 ` Benjamin Herrenschmidt
2009-02-04 5:13 ` Andrew Morton
2009-02-04 5:13 ` Andrew Morton
2009-02-04 5:31 ` Nick Piggin
2009-02-04 5:31 ` Nick Piggin
2009-02-04 6:17 ` wli
2009-02-04 6:17 ` wli
2009-02-04 6:16 ` Roland Dreier
2009-02-04 6:16 ` Roland Dreier
2009-02-04 6:26 ` Andrew Morton
2009-02-04 6:26 ` Andrew Morton
2009-02-04 19:11 ` Roland Dreier
2009-02-04 19:11 ` Roland Dreier
2009-02-04 21:00 ` wli
2009-02-04 21:00 ` wli
2009-02-04 21:31 ` Roland Dreier
2009-02-04 21:31 ` Roland Dreier
2009-02-04 21:23 ` Andrew Morton
2009-02-04 21:23 ` Andrew Morton
2009-02-04 23:55 ` Benjamin Herrenschmidt
2009-02-04 23:55 ` Benjamin Herrenschmidt
2009-02-05 5:10 ` Roland Dreier
2009-02-05 5:10 ` Roland Dreier
2009-02-05 5:24 ` Benjamin Herrenschmidt
2009-02-05 5:24 ` Benjamin Herrenschmidt
2009-02-05 5:33 ` Roland Dreier [this message]
2009-02-05 5:33 ` Roland Dreier
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=adawsc5jvm9.fsf@cisco.com \
--to=rdreier@cisco.com \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=eli@mellanox.co.il \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=rusty@rustcorp.com.au \
/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.