All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Robin Holt <holt@sgi.com>
Cc: Christoph Hellwig <hch@infradead.org>, Dean Nelson <dcn@sgi.com>,
	tony.luck@intel.com, linux-ia64@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	akpm@linux-foundation.org, jes@sgi.com
Subject: Re: [PATCH 4/4] add SGI Altix cross partition memory (XPMEM) driver
Date: Tue, 28 Aug 2007 19:05:10 +0000	[thread overview]
Message-ID: <20070828190510.GA3256@infradead.org> (raw)
In-Reply-To: <20070828190043.GB7140@lnx-holt.americas.sgi.com>

On Tue, Aug 28, 2007 at 02:00:43PM -0500, Robin Holt wrote:
> The ioctl is sort of historical.  IIRC, in ProPack 3 (RHEL4 based 2.4
> kernel), we added system calls.  When the community started making noise
> about system calls being bad, we went to a device special file with a
> read/write (couldn't get the needed performance from the ioctl() interface
> which used to acquire the BKL).  Now that the community fixed the ioctl
> issues, we went to using an ioctl, but are completely open to change.
> 
> If you want to introduce system calls, we would expect to need, IIRC, 8.
> We also pondered an xpmem filesystem today.  It really felt wrong,
> but we could pursue that as an alternative.

The problem is not ioctls per sæ, but the kind of operation you
export.

> What is the correct direction to go with this?  get_user_pages() does
> currently require the task_struct.  Are you proposing we develop a way
> to fault pages without the task_struct of the owning process/thread group?

Stop trying to mess with vmas and get_user_pages on processes entirely.
The only region of virtual memory a driver can deal with is the one it
got a mmap request for, or when using get_user_pages the one it's got
a read/write request for.  You're doing a worse variant of the rdma page
pinning scheme we're rejected countless times.

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Robin Holt <holt@sgi.com>
Cc: Christoph Hellwig <hch@infradead.org>, Dean Nelson <dcn@sgi.com>,
	tony.luck@intel.com, linux-ia64@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	akpm@linux-foundation.org, jes@sgi.com
Subject: Re: [PATCH 4/4] add SGI Altix cross partition memory (XPMEM) driver
Date: Tue, 28 Aug 2007 20:05:10 +0100	[thread overview]
Message-ID: <20070828190510.GA3256@infradead.org> (raw)
In-Reply-To: <20070828190043.GB7140@lnx-holt.americas.sgi.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 1325 bytes --]

On Tue, Aug 28, 2007 at 02:00:43PM -0500, Robin Holt wrote:
> The ioctl is sort of historical.  IIRC, in ProPack 3 (RHEL4 based 2.4
> kernel), we added system calls.  When the community started making noise
> about system calls being bad, we went to a device special file with a
> read/write (couldn't get the needed performance from the ioctl() interface
> which used to acquire the BKL).  Now that the community fixed the ioctl
> issues, we went to using an ioctl, but are completely open to change.
> 
> If you want to introduce system calls, we would expect to need, IIRC, 8.
> We also pondered an xpmem filesystem today.  It really felt wrong,
> but we could pursue that as an alternative.

The problem is not ioctls per sæ, but the kind of operation you
export.

> What is the correct direction to go with this?  get_user_pages() does
> currently require the task_struct.  Are you proposing we develop a way
> to fault pages without the task_struct of the owning process/thread group?

Stop trying to mess with vmas and get_user_pages on processes entirely.
The only region of virtual memory a driver can deal with is the one it
got a mmap request for, or when using get_user_pages the one it's got
a read/write request for.  You're doing a worse variant of the rdma page
pinning scheme we're rejected countless times.

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Robin Holt <holt@sgi.com>
Cc: Christoph Hellwig <hch@infradead.org>, Dean Nelson <dcn@sgi.com>,
	tony.luck@intel.com, linux-ia64@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	akpm@linux-foundation.org, jes@sgi.com
Subject: Re: [PATCH 4/4] add SGI Altix cross partition memory (XPMEM) driver
Date: Tue, 28 Aug 2007 20:05:10 +0100	[thread overview]
Message-ID: <20070828190510.GA3256@infradead.org> (raw)
In-Reply-To: <20070828190043.GB7140@lnx-holt.americas.sgi.com>

On Tue, Aug 28, 2007 at 02:00:43PM -0500, Robin Holt wrote:
> The ioctl is sort of historical.  IIRC, in ProPack 3 (RHEL4 based 2.4
> kernel), we added system calls.  When the community started making noise
> about system calls being bad, we went to a device special file with a
> read/write (couldn't get the needed performance from the ioctl() interface
> which used to acquire the BKL).  Now that the community fixed the ioctl
> issues, we went to using an ioctl, but are completely open to change.
> 
> If you want to introduce system calls, we would expect to need, IIRC, 8.
> We also pondered an xpmem filesystem today.  It really felt wrong,
> but we could pursue that as an alternative.

The problem is not ioctls per sae, but the kind of operation you
export.

> What is the correct direction to go with this?  get_user_pages() does
> currently require the task_struct.  Are you proposing we develop a way
> to fault pages without the task_struct of the owning process/thread group?

Stop trying to mess with vmas and get_user_pages on processes entirely.
The only region of virtual memory a driver can deal with is the one it
got a mmap request for, or when using get_user_pages the one it's got
a read/write request for.  You're doing a worse variant of the rdma page
pinning scheme we're rejected countless times.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2007-08-28 19:05 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-27 15:56 [PATCH 0/4] SGI Altix cross partition memory (XPMEM) Dean Nelson
2007-08-27 15:56 ` Dean Nelson
2007-08-27 15:56 ` Dean Nelson
2007-08-27 15:59 ` [PATCH 1/4] export __put_task_struct for XPMEM Dean Nelson
2007-08-27 15:59   ` Dean Nelson
2007-08-27 15:59   ` Dean Nelson
2007-08-27 16:13   ` Al Viro
2007-08-27 16:13     ` Al Viro
2007-08-27 16:13     ` Al Viro
2007-08-27 18:10     ` Dean Nelson
2007-08-27 18:10       ` Dean Nelson
2007-08-27 18:10       ` Dean Nelson
2007-08-27 18:15       ` Al Viro
2007-08-27 18:15         ` Al Viro
2007-08-27 18:15         ` Al Viro
2007-08-27 19:19         ` Dean Nelson
2007-08-27 19:19           ` Dean Nelson
2007-08-27 19:19           ` Dean Nelson
2007-08-27 19:35           ` Al Viro
2007-08-27 19:35             ` Al Viro
2007-08-27 19:35             ` Al Viro
2007-08-27 20:24             ` Robin Holt
2007-08-27 20:24               ` Robin Holt
2007-08-27 20:24               ` Robin Holt
2007-08-27 20:47               ` Al Viro
2007-08-27 20:47                 ` Al Viro
2007-08-27 20:47                 ` Al Viro
2007-08-28 12:09                 ` Robin Holt
2007-08-28 18:01       ` Christoph Hellwig
2007-08-28 18:01         ` Christoph Hellwig
2007-08-28 18:01         ` Christoph Hellwig
2007-08-27 16:01 ` [PATCH 2/4] export zap_page_range " Dean Nelson
2007-08-27 16:01   ` Dean Nelson
2007-08-27 16:01   ` Dean Nelson
2007-08-27 16:02 ` [PATCH 3/4] add new lock ordering rule to mm/filemap.c Dean Nelson
2007-08-27 16:02   ` Dean Nelson
2007-08-27 16:02   ` Dean Nelson
2007-08-27 16:41 ` [PATCH 4/4] add SGI Altix cross partition memory (XPMEM) driver Dean Nelson
2007-08-27 16:41   ` Dean Nelson
2007-08-27 20:00   ` Adrian Bunk
2007-08-27 20:00     ` Adrian Bunk
2007-08-27 20:00     ` Adrian Bunk
2007-08-28 18:02   ` Christoph Hellwig
2007-08-28 18:02     ` Christoph Hellwig
2007-08-28 18:02     ` Christoph Hellwig
2007-08-28 19:00     ` Robin Holt
2007-08-28 19:00       ` Robin Holt
2007-08-28 19:00       ` Robin Holt
2007-08-28 19:05       ` Christoph Hellwig [this message]
2007-08-28 19:05         ` Christoph Hellwig
2007-08-28 19:05         ` Christoph Hellwig

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=20070828190510.GA3256@infradead.org \
    --to=hch@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=dcn@sgi.com \
    --cc=holt@sgi.com \
    --cc=jes@sgi.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=tony.luck@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.