Re: [RFC] Add swappiness argument to memory.reclaim

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

 



On Tue, May 17, 2022 at 9:05 AM Roman Gushchin <roman.gushchin@xxxxxxxxx> wrote:
>
> On Mon, May 16, 2022 at 03:29:42PM -0700, Yosry Ahmed wrote:
> > The discussions on the patch series [1] to add memory.reclaim has
> > shown that it is desirable to add an argument to control the type of
> > memory being reclaimed by invoked proactive reclaim using
> > memory.reclaim.
> >
> > I am proposing adding a swappiness optional argument to the interface.
> > If set, it overwrites vm.swappiness and per-memcg swappiness. This
> > provides a way to enforce user policy on a stateless per-reclaim
> > basis. We can make policy decisions to perform reclaim differently for
> > tasks of different app classes based on their individual QoS needs. It
> > also helps for use cases when particularly page cache is high and we
> > want to mainly hit that without swapping out.
> >
> > The interface would be something like this (utilizing the nested-keyed
> > interface we documented earlier):
> >
> > $ echo "200M swappiness=30" > memory.reclaim
>
> What are the anticipated use cases except swappiness == 0 and
> swappiness == system_default?
>
> IMO it's better to allow specifying the type of memory to reclaim,
> e.g. type="file"/"anon"/"slab", it's a way more clear what to expect.

I imagined swappiness would give user space flexibility to reclaim a
ratio of file vs. anon as it sees fit based on app class or userspace
policy, but I agree that the guarantees of swappiness are weak and we
might want an explicit argument that directly controls the return
value of get_scan_count() or whether or not we call shrink_slab(). My
fear is that this interface may be less flexible, for example if we
only want to avoid reclaiming file pages, but we are fine with anon or
slab. Maybe in the future we will have a new type of memory to
reclaim, does it get implicitly reclaimed when other types are
specified or not?

Maybe we can use one argument per type instead? E.g.
    $ echo "200M file=no anon=yes slab=yes" > memory.reclaim

The default value would be "yes" for all types unless stated
otherwise. This is also leaves room for future extensions (maybe
file=clean to reclaim clean file pages only?). Interested to hear your
thoughts on this!

>
> E.g. what
> $ echo "200M swappiness=1" > memory.reclaim
> means if there is only 10M of pagecache? How much of anon memory will
> be reclaimed?

Good point. I agree that the type argument or per-type arguments have
multiple advantages over swappiness.

>
> Thanks!




[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