Hi Ju Hyung, On 2019/5/14 17:51, Ju Hyung Park wrote: > Hi Chao, > > On Tue, May 14, 2019 at 6:20 PM Chao Yu <[email protected] > <mailto:[email protected]>> wrote: >> IIRC, related interfaces (gc_urgent/urgent_sleep_time) were introduced for >> Android Go > > These are used for all Android devices since Pie, and is triggered when > Android > thinks the device is idle. iirc, screen state is one of them to ensure that > the > user isn't using any apps. > >> may be stuck due to racing with IO from GC. Anyway I think we need to set >> proper >> interval for background GC, IMO, 1 ms is too short... > > 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? > > I think we're thinking too theoretical and failing to address real practical > issues. > > Also, if that's a concern, the userspace shouldn't use gc_urgent at all. We > have > other tunables for tuning regular GC. Yes, we can, but there is no sysfs entry can make GC running as IO non-awareness, I guess that's why Jaegeuk expose independent entry. > > Similar to fstrim on traditional filesystems(blocking everything until all > trim > is done), this is supposed to be a userspace hint to run GC aggressively in > system where the in-kernel is_idle() isn't enough, and as it's an interface > for > "aggressive" GC, it should finish as soon as possible imo. 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. > Userspace should be calling this when it knows that the device is idle, or > when > it's willing to sacrifice some latency. > > The default 500ms didn't make much sense and causes real-world problem as vold > only waits 480 seconds. I don't remember the threshold in Android Go (Oreo)... 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. Thanks, > > Thanks. _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
