On Mon, Jun 20, 2022 at 10:38:43AM -0700, Daeho Jeong wrote: > From: Daeho Jeong <[email protected]> > > Now decompression is being handled in workqueue and it makes read I/O > latency non-deterministic, because of the non-deterministic scheduling > nature of workqueues. So, I made it handled in softirq context only if > possible, not in low memory devices, since this modification will > maintain decompresion related memory a little longer. >
Again, I don't think this method scalable. Since you already handle all decompression algorithms in this way. Laterly, I wonder if you'd like to handle all: - decompression algorithms; - verity algorithms; - decrypt algorithms; in this way, regardless of slow decompression algorithms, that would be a long latency and CPU overhead of softirq context. This is my last words on this, I will not talk anymore. Thanks, Gao Xiang _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
