On 01/02/18 20:34, Chuck Lever wrote: <> > This work was also presented at the SNIA Persistent Memory Summit last week. > The use case of course is providing a user space platform for the development > and deployment of memory-based file systems. The value-add of this kind of > file system is ultra-low latency, which is a challenge for the current most > popular such framework, FUSE. > > To start, I can think of three areas where specific questions might be > entertained by LSF/MM attendees: > > - Spectre mitigations make this whole "user space filesystem" arrangement even > slower, thanks to additional context switches between user space and the kernel. > What can be done for FUSE and ZUFS to reduce the impact of Spectre mitigations? > Sigh !! What about a different interface for a "trusted" binary with "Spectre mitigation" off. I know Redhat guys have a project where they want to sign and verify by Kernel all systemd /sbin/* binaries. If these binaries have such an hardened trust could we make them faster? (ie back to regular speed) > - The fundamental innovation of ZUFS is porting Solaris "doors" to Linux. A > "door" is a local RPC mechanism that stays on the same thread to reduce > scheduling overhead during calls to services provided by daemons on the local > system. Is there interest in building a generic "doors" facility in Linux? > People said I should look into the Binder project from Google. It is already in Kernel, and is used by Android. As I understand they have exactly such an object like you describe above. Combined with my thread-array it sounds like what I want. > - ZUFS currently supports only synchronous calls to the file system, as the > assumption is the services (filesystems) will be I/O-less, typically. Is there > a need to support asynchronicity in the ZUFS API? > There is a plan for async ops, the Server returns "PENDING" and then the Operation is completed later by the server on some Async back channel. With some kind of a cookie system. But I have not come to implement it yet. This will cost because it will need a double mapping of application pages. But I assume async means it is slower, and it is still cheaper then copy. So yes, it is on the roadmap. In General locks are OK in a sync-operation but any need for re-entering the Kernel, Say to read from disk, will need to be completed ASYNC and the zt-channel freed for other operations. > > -- > Chuck Lever > Thanks Boaz
