> I have an ugly patch which uses IDR as Miklos asked, but unfortunately > I'm facing some performance issues due to the locking mechanisms to keep > guarantee the RCU consistency. I can post the new patch set as an RFC > soon for the community to take a look. > At a glance what happens is: > - the IDR, one for each fuse_conn, contains pointers to "struct > fuse_passthrough" containing: > - fuse_file *: which is using passthrough, > - file *: native file system file target, > - cred of the FUSE server, > - ioctl(PASSTHROUGH_OPEN): updates IDR, requires spinlock: > - kmalloc(fuse_passthrough), update file and cred, > - ID = idr_alloc(), > - return ID, > - fuse_open reply from FUSE server with passthrough ID: updates IDR, > requires spinlock: > - pt = idr_find(ID), > - update fuse_file with the current fuse_file, > - update fuse_file->passthrough_id = ID, > - idr_replace(), > - read/write/mmap: lock-free IDR read: > - idr_find(fuse_file::passthrough_id), > - forward request to lower file system as for the current FUSE > passthrough patches. > - ioctl(PASSTHROUGH_CLOSE): updates IDR, requires spinlock: > - idr_remove(); > - call_rcu(): tell possible open fuse_file user that the ID is no more > valid and kfree() the allocated struct; > - close(fuse_file): updates IDR, requires spinlock: > - ID = fuse_file::passthrough_id > - idr_find(ID), > - fuse_passthrough::fuse_file = NULL, > - idr_replace(). > > This would be fine if passthrough is activated for a few, big files, > where the passthrough overhead is dominated by the direct access > benefits, but if passthrough is enabled for many small files which just > do one or two read/writes (as what I did for my benchmark of total build > time for the kernel, where I was passing-through every opened file), the > overhead becomes a real issue. > > If you have any thoughts on how to make this simpler, I'm absolutely > open to fix this. > This IDR namespace usually serves a single process. Right? It sounds a bit more like a file table, more specifically, like io_file_table. I may be way off, but this sounds a bit like IORING_REGISTER_FILES. Is there anything that can be learned from this UAPI? Maybe even reuse of some of the io_uring file register code? Thanks, Amir.
