From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> To: Andrew Morton <akpm@linux-foundation.org> Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "nishimura@mxp.nes.nec.co.jp" <nishimura@mxp.nes.nec.co.jp>, "bsingharora@gmail.com" <bsingharora@gmail.com>, Michal Hocko <mhocko@suse.cz>, Ying Han <yinghan@google.com>, Shaohua Li <shaohua.li@intel.com>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Subject: Re: [PATCH] [Cleanup] memcg: export memory cgroup's swappiness v2 Date: Fri, 1 Jul 2011 10:16:24 +0900 [thread overview] Message-ID: <20110701101624.a10b7e34.kamezawa.hiroyu@jp.fujitsu.com> (raw) In-Reply-To: <20110630180653.1df10f38.akpm@linux-foundation.org> On Thu, 30 Jun 2011 18:06:53 -0700 Andrew Morton <akpm@linux-foundation.org> wrote: > On Fri, 1 Jul 2011 09:20:59 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote: > > > On Fri, 1 Jul 2011 08:50:13 +0900 > > KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote: > > > > > On Thu, 30 Jun 2011 13:01:34 -0700 > > > Andrew Morton <akpm@linux-foundation.org> wrote: > > > > > Ok, I'll check it. Maybe I miss !CONFIG_SWAP... > > > > > > > v4 here. Thank you for pointing out. I could think of several ways but > > maybe this one is good because using vm_swappines with !CONFIG_SWAP seems > > to be a bug. > > No, it isn't a bug - swappiness also controls the kernel's eagerness to > unmap and reclaim mmapped pagecache. > Oh, really ? I didn't understand that. > > tested with allyesconfig/allnoconfig. > > Did it break the above? > Hmm. If !CONFIG_SWAP, get_scan_count() will see !nr_swap_pages and set scan ratio as file: 100% anon: 0% > > +#ifdef CONFIG_SWAP > > +static int vmscan_swappiness(struct scan_control *sc) > > +{ > > + if (scanning_global_lru(sc)) > > + return vm_swappiness; > > Well that's a bit ugly - it assumes that all callers set > scan_control.swappiness to vm_swappiness then never change it. That > may be true in the current code. > > Ho hum, I guess that's a simplification we can make. > We don't calculate kernel internal swappiness and just use vm_swappines which the user specified. So, I thought it should not be in scan_control. > > + return mem_cgroup_swappiness(sc->mem_cgroup); > > +} > > +#else > > +static int vmscan_swappiness(struct scan_control *sc) > > +{ > > + /* Now, this function is never called with !CONFIG_SWAP */ > > + BUG(); > > + return 0; > > +} > > +#endif > > > > ... > > > > @@ -1789,8 +1804,8 @@ static void get_scan_count(struct zone *zone, struct scan_control *sc, > > * With swappiness at 100, anonymous and file have the same priority. > > * This scanning priority is essentially the inverse of IO cost. > > */ > > - anon_prio = sc->swappiness; > > - file_prio = 200 - sc->swappiness; > > + anon_prio = vmscan_swappiness(sc); > > + file_prio = 200 - vmscan_swappiness(sc); > > hah, this should go BUG if CONFIG_SWAP=n. But it won't, because we > broke get_scan_count(). It fails to apply vm_swappiness to file-backed > pages if there's no available swap, which is daft. > > I think this happened in 76a33fc380c9a ("vmscan: prevent > get_scan_ratio() rounding errors") which claims "this patch doesn't > really change logics, but just increase precision". > Hmm, IIUC. - the controller of unmapping file cache is now sc->may_unmap - may_unmap is always set 1 unless zone_reclaim_mode. - vm_swappiness doesn't affect it now. - file LRU contains both mapped and unmapped pages in the same manner - get_scan_count() cannot help decisiion of "map or unmap" - Active/Inactive scan ratio is now determined by reclaim_stat. Hmm, swappiness should affect active/inactive scan ratio ? Thanks, -Kame
WARNING: multiple messages have this Message-ID (diff)
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> To: Andrew Morton <akpm@linux-foundation.org> Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "nishimura@mxp.nes.nec.co.jp" <nishimura@mxp.nes.nec.co.jp>, "bsingharora@gmail.com" <bsingharora@gmail.com>, Michal Hocko <mhocko@suse.cz>, Ying Han <yinghan@google.com>, Shaohua Li <shaohua.li@intel.com>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Subject: Re: [PATCH] [Cleanup] memcg: export memory cgroup's swappiness v2 Date: Fri, 1 Jul 2011 10:16:24 +0900 [thread overview] Message-ID: <20110701101624.a10b7e34.kamezawa.hiroyu@jp.fujitsu.com> (raw) In-Reply-To: <20110630180653.1df10f38.akpm@linux-foundation.org> On Thu, 30 Jun 2011 18:06:53 -0700 Andrew Morton <akpm@linux-foundation.org> wrote: > On Fri, 1 Jul 2011 09:20:59 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote: > > > On Fri, 1 Jul 2011 08:50:13 +0900 > > KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote: > > > > > On Thu, 30 Jun 2011 13:01:34 -0700 > > > Andrew Morton <akpm@linux-foundation.org> wrote: > > > > > Ok, I'll check it. Maybe I miss !CONFIG_SWAP... > > > > > > > v4 here. Thank you for pointing out. I could think of several ways but > > maybe this one is good because using vm_swappines with !CONFIG_SWAP seems > > to be a bug. > > No, it isn't a bug - swappiness also controls the kernel's eagerness to > unmap and reclaim mmapped pagecache. > Oh, really ? I didn't understand that. > > tested with allyesconfig/allnoconfig. > > Did it break the above? > Hmm. If !CONFIG_SWAP, get_scan_count() will see !nr_swap_pages and set scan ratio as file: 100% anon: 0% > > +#ifdef CONFIG_SWAP > > +static int vmscan_swappiness(struct scan_control *sc) > > +{ > > + if (scanning_global_lru(sc)) > > + return vm_swappiness; > > Well that's a bit ugly - it assumes that all callers set > scan_control.swappiness to vm_swappiness then never change it. That > may be true in the current code. > > Ho hum, I guess that's a simplification we can make. > We don't calculate kernel internal swappiness and just use vm_swappines which the user specified. So, I thought it should not be in scan_control. > > + return mem_cgroup_swappiness(sc->mem_cgroup); > > +} > > +#else > > +static int vmscan_swappiness(struct scan_control *sc) > > +{ > > + /* Now, this function is never called with !CONFIG_SWAP */ > > + BUG(); > > + return 0; > > +} > > +#endif > > > > ... > > > > @@ -1789,8 +1804,8 @@ static void get_scan_count(struct zone *zone, struct scan_control *sc, > > * With swappiness at 100, anonymous and file have the same priority. > > * This scanning priority is essentially the inverse of IO cost. > > */ > > - anon_prio = sc->swappiness; > > - file_prio = 200 - sc->swappiness; > > + anon_prio = vmscan_swappiness(sc); > > + file_prio = 200 - vmscan_swappiness(sc); > > hah, this should go BUG if CONFIG_SWAP=n. But it won't, because we > broke get_scan_count(). It fails to apply vm_swappiness to file-backed > pages if there's no available swap, which is daft. > > I think this happened in 76a33fc380c9a ("vmscan: prevent > get_scan_ratio() rounding errors") which claims "this patch doesn't > really change logics, but just increase precision". > Hmm, IIUC. - the controller of unmapping file cache is now sc->may_unmap - may_unmap is always set 1 unless zone_reclaim_mode. - vm_swappiness doesn't affect it now. - file LRU contains both mapped and unmapped pages in the same manner - get_scan_count() cannot help decisiion of "map or unmap" - Active/Inactive scan ratio is now determined by reclaim_stat. Hmm, swappiness should affect active/inactive scan ratio ? Thanks, -Kame -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-07-01 1:23 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-06-29 10:03 [PATCH] [Cleanup] memcg: export memory cgroup's swappiness v2 KAMEZAWA Hiroyuki 2011-06-29 10:03 ` KAMEZAWA Hiroyuki 2011-06-29 12:20 ` Michal Hocko 2011-06-29 12:20 ` Michal Hocko 2011-06-29 13:00 ` Balbir Singh 2011-06-29 13:00 ` Balbir Singh 2011-06-29 20:00 ` Andrew Morton 2011-06-29 20:00 ` Andrew Morton 2011-06-30 3:32 ` KAMEZAWA Hiroyuki 2011-06-30 3:32 ` KAMEZAWA Hiroyuki 2011-06-30 6:32 ` Michal Hocko 2011-06-30 6:32 ` Michal Hocko 2011-06-30 7:10 ` KAMEZAWA Hiroyuki 2011-06-30 7:10 ` KAMEZAWA Hiroyuki 2011-06-30 7:33 ` Michal Hocko 2011-06-30 7:33 ` Michal Hocko 2011-06-30 20:01 ` Andrew Morton 2011-06-30 20:01 ` Andrew Morton 2011-06-30 23:50 ` KAMEZAWA Hiroyuki 2011-06-30 23:50 ` KAMEZAWA Hiroyuki 2011-07-01 0:20 ` KAMEZAWA Hiroyuki 2011-07-01 0:20 ` KAMEZAWA Hiroyuki 2011-07-01 1:06 ` Andrew Morton 2011-07-01 1:06 ` Andrew Morton 2011-07-01 1:16 ` KAMEZAWA Hiroyuki [this message] 2011-07-01 1:16 ` KAMEZAWA Hiroyuki 2011-07-01 1:30 ` KAMEZAWA Hiroyuki 2011-07-01 1:30 ` KAMEZAWA Hiroyuki 2011-07-01 7:10 ` KAMEZAWA Hiroyuki 2011-07-01 7:10 ` KAMEZAWA Hiroyuki 2011-07-06 5:18 ` [PATCH] [Cleanup] memcg: export memory cgroup's swappiness v5 KAMEZAWA Hiroyuki 2011-07-06 5:18 ` KAMEZAWA Hiroyuki
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=20110701101624.a10b7e34.kamezawa.hiroyu@jp.fujitsu.com \ --to=kamezawa.hiroyu@jp.fujitsu.com \ --cc=akpm@linux-foundation.org \ --cc=bsingharora@gmail.com \ --cc=kosaki.motohiro@jp.fujitsu.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhocko@suse.cz \ --cc=nishimura@mxp.nes.nec.co.jp \ --cc=shaohua.li@intel.com \ --cc=yinghan@google.com \ /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: linkBe 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.