On Tue, Jan 11, 2022 at 11:58:07AM +0100, Christian König wrote:
This is also not a problem due to the high number of DMA-BUF exports during launch time, as even a single export can be delayed for an unpredictable amount of time. We cannot eliminate DMA-BUF exports completely during app-launches and we are unfortunately seeing reports of the exporting process occasionally sleeping long enough to cause user-visible jankiness :(
We also looked at whether any optimizations are possible from the kernfs implementation side[1] but the semaphore is used quite extensively and it looks like the best way forward would be to remove sysfs creation/teardown from the DMA-BUF export/release path altogether. We have some ideas on how we can reduce the code-complexity in the current patch. If we manage to simplify it considerably, would the approach of offloading sysfs creation and teardown into a separate thread be acceptable Christian?
At bare minimum I suggest to use a work_struct instead of re-inventing that with kthread.
And then only put the exporting of buffers into the background and not the teardown.
Thank you for the guidance!
One worry I have here with doing this async that now userspace might have a dma-buf, but the sysfs entry does not yet exist, or the dma-buf is gone, but the sysfs entry still exists. That's a bit awkward wrt semantics.
Also I'm pretty sure that if we can hit this, then other subsystems using kernfs have similar problems, so trying to fix this in kernfs with slightly more fine-grained locking sounds like a much more solid approach. The linked patch talks about how the big delays happen due to direct reclaim, and that might be limited to specific code paths that we need to look at? As-is this feels a bit much like papering over kernfs issues in hackish ways in sysfs users, instead of tackling the problem at its root.
Which is exactly my feeling as well, yes.
More and more people are using sysfs/kernfs now for things that it was never designed for (i.e. high-speed statistic gathering). That's not the fault of kernfs, it's the fault of people thinking it can be used for stuff like that :)
But delays like this is odd, tearing down sysfs attributes should normally _never_ be a fast-path that matters to system throughput. So offloading it to a workqueue makes sense as the attributes here are for objects that are on the fast-path.
thanks,
greg k-h