From: Roland Dreier <rdreier@cisco.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
Brice Goglin <Brice.Goglin@inria.fr>,
linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org,
general@lists.openfabrics.org, akpm@linux-foundation.org,
torvalds@linux-foundation.org
Cc: jsquyres@cisco.com
Subject: Re: [ofa-general] Re: [GIT PULL] please pull ummunotify
Date: Tue, 15 Sep 2009 01:27:57 -0700 [thread overview]
Message-ID: <adad45shasy.fsf@cisco.com> (raw)
In-Reply-To: <20090915155231.DB86.A69D9226@jp.fujitsu.com> (KOSAKI Motohiro's message of "Tue, 15 Sep 2009 16:03:04 +0900 (JST)")
> - I guess you have your MPI implementaion w/ ummunotify, right?
Yes, Jeff Squyres (cc'ed) has an Open MPI prototype (mercurial tree at
http://bitbucket.org/jsquyres/ummunot/).
> - I guess you have test sevaral pattern, right?
> if so, can we see your test result?
Open MPI has a pretty extensive automated test fabric -- I don't have a
link handy but I believe all the tests that pass with unmodified Open
MPI currently still pass with ummunotify. Maybe Jeff has a link.
> - I think you can explain your MPI advantage/disadvantage against
> current OpenMPI (or mpich et al).
The advantage is as Jeff explained in his blog post
(http://blogs.cisco.com/ciscotalk/performance/comments/better_linux_memory_tracking/),
namely the performance improvement of memory registration caching
without the reliability problems caused by previous approaches to
caching such as trying to hook malloc etc (which are fragile because the
great diversity of MPI-using codes find ways to mess up all previous
userspace-only approaches).
> - I guess your patch dramatically improve MPI implementaion, but
> it's not free. it request some limitation to MPI application, right?
Not that I know of, beyond already existing limitations.
> - I imagine multi thread and fork. Is there another linmitaion?
There are no new limitations on multi-threaded codes or on use of fork
that I know of. Of course, buggy code that does something like passing
a buffer to MPI in one thread and then freeing that buffer from another
thread before MPI is done with it is still buggy; but ummunotify
actually increases the ability of the MPI implementation to detect such
bugs and give useful diagnostic information.
> - In past discuttion, you said ummunotify user should not use
> multi threading. you also think user should not fork?
I don't recall where I said ummunotify users should not be
multithreaded. I don't know of any problem with that.
Also code using ummunotify can fork -- ummunotify simply does not fix
issues with copy-on-write for buffers that are in use, just as it does
not fix multithreaded code that has a race between using a buffer and
freeing the same buffer.
Hope this clarifies things.
- Roland
next prev parent reply other threads:[~2009-09-15 8:28 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-11 4:38 [GIT PULL] please pull ummunotify Roland Dreier
2009-09-11 5:56 ` KOSAKI Motohiro
2009-09-11 6:03 ` Roland Dreier
2009-09-11 6:11 ` KOSAKI Motohiro
2009-09-11 16:42 ` Gleb Natapov
2009-09-11 6:15 ` Brice Goglin
2009-09-11 6:21 ` KOSAKI Motohiro
2009-09-11 6:22 ` Roland Dreier
2009-09-11 6:40 ` [ofa-general] " Jason Gunthorpe
2009-09-11 16:58 ` Roland Dreier
2009-09-15 7:03 ` KOSAKI Motohiro
2009-09-15 8:27 ` Roland Dreier [this message]
2009-09-15 12:38 ` Jeff Squyres
2009-09-15 11:34 ` Pavel Machek
2009-09-15 14:57 ` [ofa-general] " Roland Dreier
2009-09-28 20:49 ` Pavel Machek
2009-09-28 21:40 ` Jason Gunthorpe
2009-09-16 16:30 ` Roland Dreier
2009-09-16 16:40 ` Linus Torvalds
2009-09-17 11:30 ` Peter Zijlstra
2009-09-17 14:24 ` [ofa-general] " Roland Dreier
2009-09-17 14:32 ` Roland Dreier
2009-09-17 14:49 ` Peter Zijlstra
2009-09-17 15:03 ` Roland Dreier
2009-09-17 15:22 ` Peter Zijlstra
2009-09-17 15:45 ` Roland Dreier
2009-09-18 11:50 ` Ingo Molnar
2009-09-29 17:13 ` Pavel Machek
2009-09-30 9:44 ` Ingo Molnar
2009-09-30 16:02 ` Jason Gunthorpe
2009-10-12 18:19 ` Ingo Molnar
2009-10-12 19:30 ` Jason Gunthorpe
2009-10-12 20:20 ` Ingo Molnar
2009-10-13 4:05 ` Jason Gunthorpe
2009-10-13 6:40 ` Ingo Molnar
2009-10-13 16:27 ` Jason Gunthorpe
2009-10-13 5:43 ` Brice Goglin
2009-10-13 6:38 ` Ingo Molnar
2009-09-30 17:06 ` Roland Dreier
2009-10-02 16:32 ` Roland Dreier
2009-10-02 20:45 ` Pavel Machek
2009-10-07 22:34 ` Roland Dreier
2009-10-12 17:33 ` Peter Zijlstra
2009-09-17 14:43 ` Peter Zijlstra
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=adad45shasy.fsf@cisco.com \
--to=rdreier@cisco.com \
--cc=Brice.Goglin@inria.fr \
--cc=akpm@linux-foundation.org \
--cc=general@lists.openfabrics.org \
--cc=jgunthorpe@obsidianresearch.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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