public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: Roland Dreier <rdreier@cisco.com>
Cc: "Håkon Bugge" <Haakon.Bugge@Sun.COM>,
	"Jason Gunthorpe" <jgunthorpe@obsidianresearch.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Eric B Munson" <ebmunson@us.ibm.com>,
	linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org,
	rolandd@cisco.com, peterz@infradead.org, pavel@ucw.cz,
	mingo@elte.hu, jsquyres@cisco.com
Subject: Re: [PATCH] ummunotify: Userspace support for MMU notifications
Date: Wed, 14 Apr 2010 12:06:23 +0300	[thread overview]
Message-ID: <20100414090623.GM23554@redhat.com> (raw)
In-Reply-To: <adahbnfme0j.fsf@roland-alpha.cisco.com>

On Tue, Apr 13, 2010 at 10:57:32AM -0700, Roland Dreier wrote:
>  > It is further claimed that "… other tricks are not robust". I wrote
>  > the code used in Scali/Platform MPI handling the issue. I do not
>  > think its fair to claim that this MPI is not robust in this matter
>  > nor that is performance is bad.
> 
> The Open MPI developers have spent a lot of effort trying to handle this
> purely in userspace and still do not believe that a truly robust
> solution is possible without kernel help.  Perhaps they can expand on
> what the obstacles are.
> 
The problem is that glibc doesn't provide correct type of hooks for MPI
to use. You can hook into free(), but the hook is called when
application frees memory, not when memory is returned back to the kernel
and since MPI wants to cache registration across free()/malloc() if
possible those hooks are not good enough. To overcome this MPI tries to
provide its own memory management library (luckily glibc defines
most/all memory management functions as weak) with proper hooks present, but
that poses a whole lot of other problems and memory management is really
not MPI's job. Even if glibc will provide proper hooks some day HPC users
may want to use other, more performance oriented, memory management
libraries instead of using build in glibc one. Relying on glibc hooks
will prevent them from doing so.

--
			Gleb.

  parent reply	other threads:[~2010-04-14  9:06 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-12  6:22 [PATCH] ummunotify: Userspace support for MMU notifications Eric B Munson
2010-04-12 20:20 ` Pavel Machek
2010-04-12 23:03 ` Andrew Morton
2010-04-12 23:59   ` Jason Gunthorpe
2010-04-13  8:29     ` Håkon Bugge
2010-04-13 17:57       ` Roland Dreier
2010-04-13 18:02         ` Peter Zijlstra
2010-04-14  5:18           ` Håkon Bugge
2010-04-14  8:52           ` Gleb Natapov
2010-04-15 13:48             ` Peter Zijlstra
2010-04-14  9:06         ` Gleb Natapov [this message]
2010-04-14 14:36           ` Jeff Squyres
2010-04-17 17:41   ` Eric B Munson
2010-04-14 16:43 ` [PATCH] ummunotify: fix umn-test build Randy Dunlap
2010-04-17 17:44   ` Eric B Munson
2010-04-18 14:38     ` 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=20100414090623.GM23554@redhat.com \
    --to=gleb@redhat.com \
    --cc=Haakon.Bugge@Sun.COM \
    --cc=akpm@linux-foundation.org \
    --cc=ebmunson@us.ibm.com \
    --cc=jgunthorpe@obsidianresearch.com \
    --cc=jsquyres@cisco.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=pavel@ucw.cz \
    --cc=peterz@infradead.org \
    --cc=rdreier@cisco.com \
    --cc=rolandd@cisco.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox