[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <3251DDDA-D705-4B1E-9595-9C24709EF146@Sun.com>
Date: Tue, 13 Apr 2010 10:29:41 +0200
From: Håkon Bugge <Haakon.Bugge@....COM>
To: Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Eric B Munson <ebmunson@...ibm.com>,
linux-kernel@...r.kernel.org, linux-rdma@...r.kernel.org,
rolandd@...co.com, peterz@...radead.org, pavel@....cz,
mingo@...e.hu
Subject: Re: [PATCH] ummunotify: Userspace support for MMU notifications
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 changes memory mapping via free(),
>>> munmap(), etc. Current pure-userspace solutions using malloc hooks
>>> and other tricks are not robust, and the feeling among experts is that
>>> the issue is unfixable without kernel help.
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(), sbrk(), madvice(). What we need is glibc to provide hooks for these 4 sys calls and the general syscall() when its argument is one of the four mentioned syscalls. To me, that is what is needed, and the ummunotify direction seems way too complicated to me.
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.
Thanks, Håkon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists