Re: [OSS Proxy] [osspd:bugs] #4 alsap output too fast

[Miklos S. <mi...@sz...>]

On Tue, Feb 5, 2013 at 3:21 PM, Tejun Heo <tj...@ke...> wrote:
> Hey, Miklos.  How have you been?
>
> On Tue, Feb 5, 2013 at 6:03 AM, Miklos Szeredi <mi...@sz...> wrote:
>> Current status of mmap support is that the last patch I posted wasn't
>> liked by Linus and since then I didn't have time to work on it.
>>
>> If Tejun or anyone else wants to work on the kernel side, please don't
>> hold back ;)
>
> What was Linus' objection about?

Here's Linus' response:

| > 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?

So basically my patch did a custom client side mmap and Linus said
that that could be better implemented with shmem.  Server side mmap
wasn't involved, that's the part I didn't like about your original
approach, so a server side data store/retrieve was added instead and
osspd modified to use that.

I couldn't find anything wrong with what Linus said.  Of course it may
turn out that there's a reason why it won't work, but it doesn't sound
too difficult to implement.


> So, I was talking with Avati about gluster the other day, which makes
> pretty heavy use of FUSE and reportedly hits bottleneck due to the
> double data copy on high bandwidth configurations.  We were talking
> about ways to reduce data copy.  The only obvious thing to do is
> mapping the page cache pages into the server address space for both
> page-cached backed and O_DIRECT files, so at least we do have a much
> stronger use case for mmapping pages into server address space.  If
> direct mmapping is the way to go, I can dust off my old patches.  What
> do you think?

I think the idea to share pages through memory maps is fundamentally
flawed.  Doing zero copy with splice is saner, I think, and there's a
lot of infrastructure already there in fuse.  And in theory nothing
prevents improving that and achieving true zero copy with direct-IO
and single-copy with buffered-IO.  BTW you couldn't do server side
mapping of O_DIRECT anyway since no page cache is involved with that.

So if data copy is really the bottleneck, then please experiment with
the splice support.  It's not perfect but it already can reduce the
data copies in some cases and we can talk about improving it.

Thanks,
Miklos