All of lore.kernel.org
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: Tim Murray <timmurray@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
	Michal Hocko <mhocko@kernel.org>,
	Vladimir Davydov <vdavydov.dev@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	cgroups@vger.kernel.org, Linux-MM <linux-mm@kvack.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Patrik Torstensson <totte@google.com>,
	Android Kernel Team <kernel-team@android.com>,
	vinmenon@codeaurora.org
Subject: Re: [RFC 0/1] add support for reclaiming priorities per mem cgroup
Date: Wed, 22 Mar 2017 14:20:13 +0900	[thread overview]
Message-ID: <20170322052013.GE30149@bbox> (raw)
In-Reply-To: <20170322044117.GD30149@bbox>

On Wed, Mar 22, 2017 at 01:41:17PM +0900, Minchan Kim wrote:
> Hi Tim,
> 
> On Tue, Mar 21, 2017 at 10:18:26AM -0700, Tim Murray wrote:
> > On Sun, Mar 19, 2017 at 10:59 PM, Minchan Kim <minchan@kernel.org> wrote:
> > > However, I'm not sure your approach is good. It seems your approach just
> > > reclaims pages from groups (DEF_PRIORITY - memcg->priority) >= sc->priority.
> > > IOW, it is based on *temporal* memory pressure fluctuation sc->priority.
> > >
> > > Rather than it, I guess pages to be reclaimed should be distributed by
> > > memcg->priority. Namely, if global memory pressure happens and VM want to
> > > reclaim 100 pages, VM should reclaim 90 pages from memcg-A(priority-10)
> > > and 10 pages from memcg-B(prioirty-90).
> > 
> > This is what I debated most while writing this patch. If I'm
> > understanding your concern correctly, I think I'm doing more than
> > skipping high-priority cgroups:
> 
> Yes, that is my concern. It could give too much pressure lower-priority
> group. You already reduced scanning window for high-priority group so
> I guess it would be enough for working.
> 
> The rationale from my thining is high-priority group can have cold pages(
> for instance, used-once pages, madvise_free pages and so on) so, VM should
> age every groups to reclaim cold pages but we can reduce scanning window
> for high-priority group to keep more workingset as you did. By that, we
> already give more pressure to lower priority group than high-prioirty group.
> 
> > 
> > - If the scan isn't high priority yet, then skip high-priority cgroups.
> 
> This part is the one I think it's too much ;-)
> I think no need to skip but just reduce scanning window by the group's
> prioirty.
> 
> > - When the scan is high priority, scan fewer pages from
> > higher-priority cgroups (using the priority to modify the shift in
> > get_scan_count).
> 
> That sounds lkie a good idea but need to tune more.
> 
> How about this?
> 
> get_scan_count for memcg-A:
>         ..
>         size = lruvec_lru_size(lruvec, lru, sc->reclaim_idx) *
>                         (memcg-A / sum(memcg all priorities))
> 
> get_scan_count for memcg-B:
>         ..
>         size = lruvec_lru_size(lruvec, lru, sc->reclaim_idx) *
>                         (memcg-B / sum(memcg all priorities))
> 

Huh, correction.

        size = lruvec_lru_size(lruvec, lru, sc->reclaim_idx);
        scan = size >> sc->priority;
        scan =  scan * (sum(memcg) - memcg A) / sum(memcg);

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Minchan Kim <minchan@kernel.org>
To: Tim Murray <timmurray@google.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
	Michal Hocko <mhocko@kernel.org>,
	Vladimir Davydov <vdavydov.dev@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>, <cgroups@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Patrik Torstensson <totte@google.com>,
	Android Kernel Team <kernel-team@android.com>,
	<vinmenon@codeaurora.org>
Subject: Re: [RFC 0/1] add support for reclaiming priorities per mem cgroup
Date: Wed, 22 Mar 2017 14:20:13 +0900	[thread overview]
Message-ID: <20170322052013.GE30149@bbox> (raw)
In-Reply-To: <20170322044117.GD30149@bbox>

On Wed, Mar 22, 2017 at 01:41:17PM +0900, Minchan Kim wrote:
> Hi Tim,
> 
> On Tue, Mar 21, 2017 at 10:18:26AM -0700, Tim Murray wrote:
> > On Sun, Mar 19, 2017 at 10:59 PM, Minchan Kim <minchan@kernel.org> wrote:
> > > However, I'm not sure your approach is good. It seems your approach just
> > > reclaims pages from groups (DEF_PRIORITY - memcg->priority) >= sc->priority.
> > > IOW, it is based on *temporal* memory pressure fluctuation sc->priority.
> > >
> > > Rather than it, I guess pages to be reclaimed should be distributed by
> > > memcg->priority. Namely, if global memory pressure happens and VM want to
> > > reclaim 100 pages, VM should reclaim 90 pages from memcg-A(priority-10)
> > > and 10 pages from memcg-B(prioirty-90).
> > 
> > This is what I debated most while writing this patch. If I'm
> > understanding your concern correctly, I think I'm doing more than
> > skipping high-priority cgroups:
> 
> Yes, that is my concern. It could give too much pressure lower-priority
> group. You already reduced scanning window for high-priority group so
> I guess it would be enough for working.
> 
> The rationale from my thining is high-priority group can have cold pages(
> for instance, used-once pages, madvise_free pages and so on) so, VM should
> age every groups to reclaim cold pages but we can reduce scanning window
> for high-priority group to keep more workingset as you did. By that, we
> already give more pressure to lower priority group than high-prioirty group.
> 
> > 
> > - If the scan isn't high priority yet, then skip high-priority cgroups.
> 
> This part is the one I think it's too much ;-)
> I think no need to skip but just reduce scanning window by the group's
> prioirty.
> 
> > - When the scan is high priority, scan fewer pages from
> > higher-priority cgroups (using the priority to modify the shift in
> > get_scan_count).
> 
> That sounds lkie a good idea but need to tune more.
> 
> How about this?
> 
> get_scan_count for memcg-A:
>         ..
>         size = lruvec_lru_size(lruvec, lru, sc->reclaim_idx) *
>                         (memcg-A / sum(memcg all priorities))
> 
> get_scan_count for memcg-B:
>         ..
>         size = lruvec_lru_size(lruvec, lru, sc->reclaim_idx) *
>                         (memcg-B / sum(memcg all priorities))
> 

Huh, correction.

        size = lruvec_lru_size(lruvec, lru, sc->reclaim_idx);
        scan = size >> sc->priority;
        scan =  scan * (sum(memcg) - memcg A) / sum(memcg);

  reply	other threads:[~2017-03-22  5:20 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-17 23:16 [RFC 0/1] add support for reclaiming priorities per mem cgroup Tim Murray
2017-03-17 23:16 ` Tim Murray
2017-03-17 23:16 ` [RFC 1/1] mm, memcg: add prioritized reclaim Tim Murray
2017-03-17 23:16   ` Tim Murray
2017-03-20 14:41   ` vinayak menon
2017-03-20 14:41     ` vinayak menon
2017-03-20  5:59 ` [RFC 0/1] add support for reclaiming priorities per mem cgroup Minchan Kim
2017-03-20  5:59   ` Minchan Kim
2017-03-20 13:58   ` Vinayak Menon
2017-03-20 13:58     ` Vinayak Menon
2017-03-20 13:58     ` Vinayak Menon
2017-03-20 15:23     ` Johannes Weiner
2017-03-20 15:23       ` Johannes Weiner
2017-03-22 12:13       ` Vinayak Menon
2017-03-22 12:13         ` Vinayak Menon
2017-03-21 17:18   ` Tim Murray
2017-03-21 17:18     ` Tim Murray
2017-03-22  4:41     ` Minchan Kim
2017-03-22  4:41       ` Minchan Kim
2017-03-22  5:20       ` Minchan Kim [this message]
2017-03-22  5:20         ` Minchan Kim
2017-03-20  6:56 ` peter enderborg
2017-03-20  6:56   ` peter enderborg
2017-03-20  8:18 ` Kyungmin Park
2017-03-20  8:18   ` Kyungmin Park
     [not found] ` <20170317231636.142311-1-timmurray-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2017-03-30  5:59   ` Minchan Kim
2017-03-30  5:59     ` Minchan Kim
2017-03-30  5:59     ` Minchan Kim
2017-03-30  7:10     ` Tim Murray
2017-03-30  7:10       ` Tim Murray
2017-03-30  7:10       ` Tim Murray
2017-03-30 15:51 ` Johannes Weiner
2017-03-30 15:51   ` Johannes Weiner
     [not found]   ` <20170330155123.GA3929-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2017-03-30 16:48     ` Shakeel Butt
2017-03-30 16:48       ` Shakeel Butt
2017-03-30 16:48       ` Shakeel Butt
2017-04-13 16:03       ` Johannes Weiner
2017-04-13 16:03         ` Johannes Weiner
2017-03-30 19:40   ` Tim Murray
2017-03-30 19:40     ` Tim Murray
2017-03-30 21:54     ` Tim Murray
2017-03-30 21:54       ` Tim Murray
     [not found]     ` <CAEe=SxmpXD=f9N_i+xe6gFUKKUefJYvBd8dSwxSM+7rbBBTniw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-13  4:30       ` Minchan Kim
2017-04-13  4:30         ` Minchan Kim
2017-04-13  4:30         ` Minchan Kim
2017-04-13 16:01         ` Johannes Weiner
2017-04-13 16:01           ` Johannes Weiner
2017-04-13 16:01           ` Johannes Weiner
     [not found]           ` <20170413160147.GB29727-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2017-04-17  4:26             ` Minchan Kim
2017-04-17  4:26               ` Minchan Kim
2017-04-17  4:26               ` Minchan Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170322052013.GE30149@bbox \
    --to=minchan@kernel.org \
    --cc=cgroups@vger.kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=surenb@google.com \
    --cc=timmurray@google.com \
    --cc=totte@google.com \
    --cc=vdavydov.dev@gmail.com \
    --cc=vinmenon@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.