On Mon, Jun 20, 2022 at 5:58 PM Gao Xiang <hsiang...@linux.alibaba.com> wrote: > > On Mon, Jun 20, 2022 at 10:38:43AM -0700, Daeho Jeong wrote: > > From: Daeho Jeong <daehoje...@google.com> > > > > 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
I understand what you're worried about. However, verity cannot be inlined because of its nature triggering I/Os. Except that, other twos are almost inducing overhead comparable to memcpy. Still, decrypt part is done in a H/W way mostly these days, though. Thanks, _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
