Hi Andrew, On Wed, Feb 19, 2020 at 12:01:23PM -0800, Andrew Morton wrote: > On Tue, 18 Feb 2020 17:44:26 -0800 Minchan Kim <minchan@xxxxxxxxxx> wrote: > > > Now, we have MADV_PAGEOUT and MADV_COLD as madvise hinting API. With that, > > application could give hints to kernel what memory range are preferred to be > > reclaimed. However, in some platform(e.g., Android), the information > > required to make the hinting decision is not known to the app. > > Instead, it is known to a centralized userspace daemon(e.g., ActivityManagerService), > > and that daemon must be able to initiate reclaim on its own without any app > > involvement. > > > > This patchset doesn't seem to be getting a lot of interest from other > potential users? It seems very specialized. Are there or will there > ever be any users of this apart from one Android daemon? Quote from http://lkml.kernel.org/r/20190531064313.193437-1-minchan@xxxxxxxxxx " Brian Geffon in ChromeOS team had an experiment with process_madvise(2) Quote form him: "What I found is that by using process_madvise after a tab has been back grounded for more than 45 seconds reduced the average tab switch times by 25%! This is a huge result and very obvious validation that process_madvise hints works well for the ChromeOS use case." " > > Also, it doesn't terribly hard for ActivityManagerService to tell > another process "now run madvise with these arguments". Please explain > why this is not practical in ActivityManagerService and also within > other potential users of this syscall. I think that's the almost a same question why ptrace doesn't work so I summarizes the part in [2/7]: * makes target task runnable creates memory layout change window so hiniting a wrong vma * target task(e.g., background task) could live in little core with cpuset/group limited environment so we couldn't react quick enough, which causes more killing. Thanks.
