On Wed, 20 Feb 2008, Nick Piggin wrote:
I don't know how this is supposed to solve anything. The sleeping
problem happens I guess mostly in truncate. And all you are doing
is putting these rmap callbacks in page_mkclean and try_to_unmap.
truncate is handled by the range invalidates. This is
On Wed, Feb 27, 2008 at 02:43:41PM -0800, Christoph Lameter wrote:
Nope. unmap_mapping_range is already handled by the range callbacks.
But they're called with atomic=1 on anything but anonymous memory. I
understood Andrew asked to remove the atomic param and to allow
sleeping for all kind of
On Thu, 28 Feb 2008, Andrea Arcangeli wrote:
On Wed, Feb 27, 2008 at 02:43:41PM -0800, Christoph Lameter wrote:
Nope. unmap_mapping_range is already handled by the range callbacks.
But they're called with atomic=1 on anything but anonymous memory. I
understood Andrew asked to remove the
That is it. That is all our allowed interaction with the users process.
OK, when you said something along the lines of the MPT library has
control of the comm buffer, then I assumed it was an area of virtual
memory which is set up as part of initialization, rather than during
runtime. I
On Thursday 21 February 2008 21:58, Robin Holt wrote:
On Thu, Feb 21, 2008 at 03:20:02PM +1100, Nick Piggin wrote:
So why can't you export a device from your xpmem driver, which
can be mmap()ed to give out anonymous memory pages to be used
for these communication buffers?
On Thu, Feb 21, 2008 at 03:20:02PM +1100, Nick Piggin wrote:
So why can't you export a device from your xpmem driver, which
can be mmap()ed to give out anonymous memory pages to be used
for these communication buffers?
Because we need to have heap and stack available as well. MPT
On Wed, Feb 20, 2008 at 02:51:45PM +1100, Nick Piggin wrote:
On Wednesday 20 February 2008 14:12, Robin Holt wrote:
For XPMEM, we do not currently allow file backed
mapping pages from being exported so we should never reach this condition.
It has been an issue since day 1. We have operated
On Wed, Feb 20, 2008 at 03:00:36AM -0600, Robin Holt wrote:
On Wed, Feb 20, 2008 at 02:51:45PM +1100, Nick Piggin wrote:
On Wednesday 20 February 2008 14:12, Robin Holt wrote:
For XPMEM, we do not currently allow file backed
mapping pages from being exported so we should never reach this
On Wednesday 20 February 2008 20:00, Robin Holt wrote:
On Wed, Feb 20, 2008 at 02:51:45PM +1100, Nick Piggin wrote:
On Wednesday 20 February 2008 14:12, Robin Holt wrote:
For XPMEM, we do not currently allow file backed
mapping pages from being exported so we should never reach this
On Friday 15 February 2008 17:49, Christoph Lameter wrote:
These special additional callbacks are required because XPmem (and likely
other mechanisms) do use their own rmap (multiple processes on a series
of remote Linux instances may be accessing the memory of a process).
F.e. XPmem may have
On Wed, Feb 20, 2008 at 10:55:20AM +1100, Nick Piggin wrote:
On Friday 15 February 2008 17:49, Christoph Lameter wrote:
These special additional callbacks are required because XPmem (and likely
other mechanisms) do use their own rmap (multiple processes on a series
of remote Linux instances
On Wednesday 20 February 2008 14:12, Robin Holt wrote:
For XPMEM, we do not currently allow file backed
mapping pages from being exported so we should never reach this condition.
It has been an issue since day 1. We have operated with that assumption
for 6 years and have not had issues with
On Fri, 15 Feb 2008, Andrew Morton wrote:
+#define mmu_rmap_notifier(function, args...)
\
+ do {\
+ struct mmu_rmap_notifier *__mrn;\
+ struct
On Thu, 14 Feb 2008 22:49:04 -0800 Christoph Lameter [EMAIL PROTECTED] wrote:
These special additional callbacks are required because XPmem (and likely
other mechanisms) do use their own rmap (multiple processes on a series
of remote Linux instances may be accessing the memory of a process).
These special additional callbacks are required because XPmem (and likely
other mechanisms) do use their own rmap (multiple processes on a series
of remote Linux instances may be accessing the memory of a process).
F.e. XPmem may have to send out notifications to remote Linux instances
and receive
These special additional callbacks are required because XPmem (and likely
other mechanisms) do use their own rmap (multiple processes on a series
of remote Linux instances may be accessing the memory of a process).
F.e. XPmem may have to send out notifications to remote Linux instances
and receive
16 matches
Mail list logo
