> Yeah, I heard that you folks are really suffered from the scheduling > issues. But for my own previous experience, extra memory footprints are > really critical in Android low memory scenarios (no matter low-ended > devices or artificial workloads), it tossed me a lot. So I finally > ntroduced many inplace I/O to handle/minimize that, including inplace > I/O for compressed pages and temporary pages. > > But I'm not quite sure what's currently happening now, since we once > didn't have such non-deterministic workqueues, and I don't hear from > other landed vendors. I think it'd be better to analyse what's going > on for these kworkers from scheduling POV and why they don't schedule > in time. > > I also have an idea is much like what I'm doing now for sync > decompression, is that just before lock page and ->read_folio, we can > trigger some decompression in addition to kworker decompression, but it > needs some MM modification, as below: > > !PageUptodate(page) > > some callback to decompress in addition to kworker > > lock_page() > ->read_folio() > > If mm folks don't like it, I think RT thread is also fine after we > analysed the root cause of the kworker delay I think. > > Thanks, > Gao Xiang > > > > > Thanks,
I don't think this is not a problem with most devices, since the allocated memory is not too big and it'll be kept just as long as I/O processing is on. However, I still understand what you're worried about, so I think I can make a new mount option like "memory=low", which can be used to give a hint to F2FS to have a priority on as little memory as possible. In this mode, we will try to keep minimal memory and we can use the previous implementation for decompression. Thanks, _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
