Hi Chao, On Tue, May 14, 2019 at 8:19 PM Chao Yu <[email protected]> wrote: > > I've been using this(with a slightly different code) for years and yet to > > notice > > any spikes in lags/slowdowns. Worst scenario, I'd just have to deal with an > > added split second(100ms max?) delay in screen wake-up. > > I'm not sure about why this happened... maybe you need to do some test to > analyse the root cause of it, filesystem/device fragment? too many undiscard > space? or non-storage issue?
Um, I'm not sure you understood what I said. What I meant is that I haven't found any issues with using an approach like this(gc_urgent with 1ms sleep intervals) for years on various Android devices. > I agreed that it should done as soon as possible, but it needs to consider IO > race in between Apps after screen wake-up and BGGC to avoid potential ANR. I actually need to check whether vold turns off gc_urgent immediately after screen turns itself back on. I don't think we need to take potential ANR in to account *if* vold stops gc_urgent right after screen-on. What do you think? > It's userspace strategy, we can change both of them > (vold_wait_time/gc_urgent_sleep_time) in userspace if current value doesn't > make > any sense. Even the user can set the tunables themselves, the default should be sensical imo. An "urgent" GC that only GCs up-to 2 segments per second doesn't sound that "urgent" :p Thanks. _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
