On 26/09/2019 10:11, Miklos Szeredi wrote: > On Thu, Sep 26, 2019 at 4:08 AM Boaz Harrosh <boaz@xxxxxxxxxxxxx> wrote: > <> >> [xfs-dax] >> threads wr_iops wr_bw wr_lat > > Data missing. > Ooops sorry will send today >> [Maxdata-1.5-zufs] >> threads wr_iops wr_bw wr_lat >> 1 1041802 260,450 3.623 >> 2 1983997 495,999 3.808 >> 4 3829456 957,364 3.959 >> 7 4501154 1,125,288 5.895330 >> 8 4400698 1,100,174 6.922174 > > Just a heads up, that I have achieved similar results with a prototype > using the unmodified fuse protocol. This prototype was built with > ideas taken from zufs (percpu/lockless, mmaped dev, single syscall per > op). I found a big scheduler scalability bottleneck that is caused by > update of mm->cpu_bitmap at context switch. This can be worked > around by using shared memory instead of shared page tables, which is > a bit of a pain, but it does prove the point. Thought about fixing > the cpu_bitmap cacheline pingpong, but didn't really get anywhere. > > Are you interested in comparing zufs with the scalable fuse prototype? > If so, I'll push the code into a public repo with some instructions, > Yes please do send it. I will give it a good run. What fuseFS do you use in usermode? > Thanks, > Miklos > Thank you Miklos for looking Boaz
