[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1OMgIz-0005Wb-2a@pomaz-ex.szeredi.hu>
Date: Thu, 10 Jun 2010 13:52:17 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: Tejun Heo <tj@...nel.org>
CC: miklos@...redi.hu, hmajxxlh@...bac.com,
fuse-devel@...ts.sourceforge.net, mszeredi@...e.cz,
linux-kernel@...r.kernel.org
Subject: Re: [fuse-devel] OSS Proxy Jack slave
On Thu, 10 Jun 2010, Tejun Heo wrote:
> > First, I think server side mmap might be nice to have but not strictly
> > necessary. I looked at osspd and it just memcopies in and out of the
> > mmaped ring buffer. Replacing those memcopies with explicit syscalls
> > to get and put the data should work fine. I doubt that the latency or
> > CPU overhead introduced by the syscalls would actually matter in
> > practice.
>
> The latency and CPU overhead perse aren't problematic and for osspd,
> copying in and out should be just fine as all update events are
> clearly denoted.
Good.
> How does the kernel know when to issue store or retrieve?
No, it's userspace that initiates store and retrieve.
> > Next thing is how to deal with multiple buffers for each char device.
> > For the above to continue to work we need to make sure there's a
> > separate nodeid associated with each buffer. The most general thing
> > would be if MMAP reply contained a nodeid which identified the buffer.
> >
> > Do you see any issues with the above?
>
> It relates to the previous question but mmap can also be used without
> all updates being notified by some kind of event where the server is
> expected to watch the mmapped area and react which is okay if server
> can share the mapped page but if it has to poll by copying data out of
> kernel buffer each time, it can get prohibitively expensive unless it
> can ask kernel "what changes since when?" which would be pretty nasty
> to implement.
If necessary we could export page protection and page fault interfaces
to userspace, which would allow it to watch for changes.
But that's not needed for OSSP, right?
Thanks,
Miklos
--
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