Re: [PATCH v8 0/4] introduce memory hinting API for external process

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello.

On Mon, Jun 22, 2020 at 12:36:35PM -0700, Minchan Kim wrote:
> On Mon, Jun 22, 2020 at 12:28:56PM -0700, Minchan Kim 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.
> > 
> > To solve the concern, this patch introduces new syscall - process_madvise(2).
> > Bascially, it's same with madvise(2) syscall but it has some differences.
> > 
> > 1. It needs pidfd of target process to provide the hint
> > 2. It supports only MADV_{COLD|PAGEOUT} at this moment.
> >    Other hints in madvise will be opened when there are explicit requests from
> >    community to prevent unexpected bugs we couldn't support.
> > 3. Only privileged processes can do something for other process's address
> >    space.
> > 
> > For more detail of the new API, please see "mm: introduce external memory hinting API"
> > description in this patchset.
> > 
> > * from v7 -  http://lore.kernel.org/r/20200302193630.68771-1-minchan@xxxxxxxxxx
> >   * dropping pid support from new syscall and fold releated patches into syscall patch
> >   * dropping KSM patch by discussion - Oleksandr, I lost the discussion.
> >     Please resend the single patch against of the patchset if you resolves the discussion.
> >     https://lore.kernel.org/linux-api/20200302193630.68771-8-minchan@xxxxxxxxxx/
> 
> Oleksandr, it seems you discussed something with Vlastimil but couldn't
> find conclustion yet and Since Jann put an a new note in the thread,
> I detach the patch from this patchset.
> 
> Please send the KSM patch based on this patchset if you belive there is
> no need to be actionable for comments.

I don't think we came to some definite conclusion, but I'll try to implement
Vlastimil's suggestion and then send it separately for evaluation.

Lets keep KSM bit out of your submission so I won't slow it down.

-- 
  Best regards,
    Oleksandr Natalenko (post-factum)
    Principal Software Maintenance Engineer





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux