From: Tejun Heo <htejun@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
alsa-devel@alsa-project.org, david.henningsson@canonical.com,
smcnam@gmail.com, gmane@colin.guthr.ie, jamescaldwell1@gmail.com,
s.maddox@lantizia.me.uk, mszeredi@suse.cz
Subject: Re: [PATCH 2/2] cuse: implement memory mapping
Date: Fri, 13 Jan 2012 10:49:13 -0800 [thread overview]
Message-ID: <20120113184913.GB11112@google.com> (raw)
In-Reply-To: <CA+55aFy7xLkMThg8+G=e7v7x7WaHSkLWGRiRF8hCq4WEUHxymw@mail.gmail.com>
Hello, Linus.
On Fri, Jan 13, 2012 at 10:19:50AM -0800, Linus Torvalds wrote:
> On Fri, Jan 13, 2012 at 9:06 AM, Miklos Szeredi <miklos@szeredi.hu> wrote:
> > From: Tejun Heo <htejun@gmail.com>
> >
> > This implements memory mapping of char devices.
>
> I don't think this is how you want to do it.
>
> It seems to maintain a page list of its own, and do the magic page
> fault etc behavior. Which to me smells like a really bad design.
>
> I would expect that what you actually want to do is to expose it as a
> shared mmap, and depend on all the normal shmem support. Is there any
> reason not to do that?
>
> I guess you don't generally have big mappings, so an argument like
> "that way you can page out pages etc" may not strike you as a very
> strong argument, but I'd still prefer to at least see that approach
> explored. Hmm?
The patch is years old and the original implementation had different
requirements (it mapped the same pages in the client's and server's
address spaces instead of using notifications). I don't really
remember the details but I tried to use shmem pretty hard but
couldn't. I *think* it was about having to accept random mapping
offset. ISTR shmem implementation wasn't too happy with randomish
high mapping offset and I couldn't shift the mapping offset due to the
direct mapping requirement (again, memory is quite fuzzy).
With notification based implementation, it might be able to just shift
the mapping offset and use shmem. Miklos, what do you think?
Thanks.
--
tejun
prev parent reply other threads:[~2012-01-13 18:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-13 17:06 [PATCH 0/2] cuse: implement mmap/munmap Miklos Szeredi
2012-01-13 17:06 ` [PATCH 1/2] fuse: create fuse_conn_operations Miklos Szeredi
2012-01-13 17:06 ` [PATCH 2/2] cuse: implement memory mapping Miklos Szeredi
2012-01-13 18:19 ` Linus Torvalds
2012-01-13 18:49 ` Tejun Heo [this message]
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=20120113184913.GB11112@google.com \
--to=htejun@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=david.henningsson@canonical.com \
--cc=gmane@colin.guthr.ie \
--cc=jamescaldwell1@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=mszeredi@suse.cz \
--cc=s.maddox@lantizia.me.uk \
--cc=smcnam@gmail.com \
--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;
as well as URLs for NNTP newsgroup(s).