On 02/02/18 11:36, Miklos Szeredi wrote: > On Thu, Feb 1, 2018 at 7:59 PM, Boaz Harrosh <boazh@xxxxxxxxxx> wrote: >> 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. > > I can see the numbers being very impressive and very happy to see > progress being made in this field. > > What I'd also really be interested to see is where those speedups come from. > > As of linux-4.2/libfuse-3.0 there is a scalability improvement, that > can be enabled with the "-o clone_fd" option. This option creates > per-thread queues, which are prerequisite to achieving full CPU/NUMA > affinity for request processing. Is it not on by default. Is there a plane to make this the default? > Even just turning of "clone_fd" > might improve the latency numbers for FUSE. > Thank you Miklos. Yes I suspect my FUSE foo is not so strong and I have not optimized FUSE for strongest numbers. Actually the only optimization I tried was increasing the number of direct IO threads to the Number of CPU's. (But that did not help much) Once the dust settles I will again conduct these tests (And so could you, I hope to release the code this week) and we should see. I have one question: If I understand correctly you expect scalability and CPU locality to highly improve with the new version and the proper configuration. Do you also expect the single thread latency to improve as well? > Thanks, > Miklos > Thanks Boaz
