Hi,
I understand that this patch went through to the -mm tree.
MVAPICH/MVAPICH2 MPI stacks intend to utilize this feature as well.
Thanks.
On Thu, Apr 22, 2010 at 6:38 AM, Eric B Munson ebmun...@us.ibm.com wrote:
From: Roland Dreier rola...@cisco.com
As discussed in
As discussed in http://article.gmane.org/gmane.linux.drivers.openib/61925
and follow-up messages, libraries using RDMA would like to track
precisely when application code changes memory mapping via free(),
munmap(), etc. Current pure-userspace solutions using malloc hooks
and other tricks
On Apr 22, 2010, at 9:38 AM, Eric B Munson wrote:
From: Roland Dreier rola...@cisco.com
As discussed in http://article.gmane.org/gmane.linux.drivers.openib/61925
and follow-up messages, libraries using RDMA would like to track
precisely when application code changes memory mapping via
From: Roland Dreier rola...@cisco.com
As discussed in http://article.gmane.org/gmane.linux.drivers.openib/61925
and follow-up messages, libraries using RDMA would like to track
precisely when application code changes memory mapping via free(),
munmap(), etc. Current pure-userspace solutions
On Mon, 12 Apr 2010, Andrew Morton wrote:
On Mon, 12 Apr 2010 07:22:17 +0100
Eric B Munson ebmun...@us.ibm.com wrote:
Andrew,
I am resubmitting this patch because I believe that the discussion
has shown this to be an acceptable solution.
To whom? Some acked-by's would clarify.
On Apr 14, 2010, at 5:06 AM, Gleb Natapov wrote:
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.
By
On Apr 13, 2010, at 1:59 , Jason Gunthorpe wrote:
On Mon, Apr 12, 2010 at 04:03:59PM -0700, Andrew Morton wrote:
As discussed in http://article.gmane.org/gmane.linux.drivers.openib/61925
and follow-up messages, libraries using RDMA would like to track
precisely when application code
I am not sure I agree with the premises here. ptMalloc and malloc
hooks are not related to the issue in my opinion. User space library
calls do not change virtual to physical mapping, system calls do. The
following sys calls might change virtual to physical mapping:
munmap(), mremap(),
On Tue, 2010-04-13 at 10:57 -0700, Roland Dreier wrote:
Are those system calls the only possible way that virtual to physical
mappings can change? Can't page migration or something like that
potentially affect things? And even if you did have hooks into every
system call that mattered (keep
On Apr 13, 2010, at 20:02 , Peter Zijlstra wrote:
Yeah, virtual-physical maps can change through swapping, page
migration, memory compaction, huge-page aggregation (the latter two not
yet being upstream).
Assuming this holds true, RDMA will not work. And with no RDMA, we do not need
Andrew,
I am resubmitting this patch because I believe that the discussion
has shown this to be an acceptable solution. I have fixed the 32 bit
build errors, but other than that change, the code is the same as
Roland's V3 patch.
From: Roland Dreier rola...@cisco.com
As discussed in
Hi!
I am resubmitting this patch because I believe that the discussion
has shown this to be an acceptable solution. I have fixed the 32 bit
build errors, but other than that change, the code is the same as
Roland's V3 patch.
From: Roland Dreier rola...@cisco.com
As discussed in
On Mon, 12 Apr 2010 07:22:17 +0100
Eric B Munson ebmun...@us.ibm.com wrote:
Andrew,
I am resubmitting this patch because I believe that the discussion
has shown this to be an acceptable solution.
To whom? Some acked-by's would clarify.
I have fixed the 32 bit
build errors, but other
13 matches
Mail list logo
