lkml.org 
[lkml]   [2020]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v6 0/7] introduce memory hinting API for external process
    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@kernel.org> 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@kernel.org

    "
    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.

    \
     
     \ /
      Last update: 2020-02-19 23:33    [W:2.681 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site