From: Christoph Lameter <cl@linux.com> To: Michal Hocko <mhocko@suse.cz> Cc: Vinayak Menon <vinmenon@codeaurora.org>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, hannes@cmpxchg.org, vdavydov@parallels.com, mgorman@suse.de, minchan@kernel.org Subject: Re: [PATCH v2] mm: vmscan: fix the page state calculation in too_many_isolated Date: Mon, 26 Jan 2015 12:35:00 -0600 (CST) [thread overview] Message-ID: <alpine.DEB.2.11.1501261233550.16786@gentwo.org> (raw) In-Reply-To: <20150126174606.GD22681@dhcp22.suse.cz> On Mon, 26 Jan 2015, Michal Hocko wrote: > > Please do not run the vmstat_updates concurrently. They update shared > > cachelines and therefore can cause bouncing cachelines if run concurrently > > on multiple cpus. > > Would you preffer to call smp_call_function_single on each CPU > which needs an update? That would make vmstat_shepherd slower but that > is not a big deal, is it? Run it from the timer interrupt as usual from a work request? Those are staggered. > Anyway I am wondering whether the cache line bouncing between > vmstat_update instances is a big deal in the real life. Updating shared > counters whould bounce with many CPUs but this is an operation which is > not done often. Also all the CPUs would have update the same counters > all the time and I am not sure this happens that often. Do you have a > load where this would be measurable? Concurrent page faults update lots of counters concurrently. But will those trigger the smp_call_function?
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Lameter <cl@linux.com> To: Michal Hocko <mhocko@suse.cz> Cc: Vinayak Menon <vinmenon@codeaurora.org>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, hannes@cmpxchg.org, vdavydov@parallels.com, mgorman@suse.de, minchan@kernel.org Subject: Re: [PATCH v2] mm: vmscan: fix the page state calculation in too_many_isolated Date: Mon, 26 Jan 2015 12:35:00 -0600 (CST) [thread overview] Message-ID: <alpine.DEB.2.11.1501261233550.16786@gentwo.org> (raw) In-Reply-To: <20150126174606.GD22681@dhcp22.suse.cz> On Mon, 26 Jan 2015, Michal Hocko wrote: > > Please do not run the vmstat_updates concurrently. They update shared > > cachelines and therefore can cause bouncing cachelines if run concurrently > > on multiple cpus. > > Would you preffer to call smp_call_function_single on each CPU > which needs an update? That would make vmstat_shepherd slower but that > is not a big deal, is it? Run it from the timer interrupt as usual from a work request? Those are staggered. > Anyway I am wondering whether the cache line bouncing between > vmstat_update instances is a big deal in the real life. Updating shared > counters whould bounce with many CPUs but this is an operation which is > not done often. Also all the CPUs would have update the same counters > all the time and I am not sure this happens that often. Do you have a > load where this would be measurable? Concurrent page faults update lots of counters concurrently. But will those trigger the smp_call_function? -- 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>
next prev parent reply other threads:[~2015-01-26 18:35 UTC|newest] Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-01-14 11:36 [PATCH v2] mm: vmscan: fix the page state calculation in too_many_isolated Vinayak Menon 2015-01-14 11:36 ` Vinayak Menon 2015-01-14 16:50 ` Michal Hocko 2015-01-14 16:50 ` Michal Hocko 2015-01-15 17:24 ` Vinayak Menon 2015-01-15 17:24 ` Vinayak Menon 2015-01-16 15:49 ` Michal Hocko 2015-01-16 15:49 ` Michal Hocko 2015-01-16 17:57 ` Michal Hocko 2015-01-16 17:57 ` Michal Hocko 2015-01-16 19:17 ` Christoph Lameter 2015-01-16 19:17 ` Christoph Lameter 2015-01-17 15:18 ` Vinayak Menon 2015-01-17 15:18 ` Vinayak Menon 2015-01-17 19:48 ` Christoph Lameter 2015-01-17 19:48 ` Christoph Lameter 2015-01-19 4:27 ` Vinayak Menon 2015-01-19 4:27 ` Vinayak Menon 2015-01-21 14:39 ` Michal Hocko 2015-01-21 14:39 ` Michal Hocko 2015-01-22 15:16 ` Vlastimil Babka 2015-01-22 15:16 ` Vlastimil Babka 2015-01-22 16:11 ` Christoph Lameter 2015-01-22 16:11 ` Christoph Lameter 2015-01-26 17:46 ` Michal Hocko 2015-01-26 17:46 ` Michal Hocko 2015-01-26 18:35 ` Christoph Lameter [this message] 2015-01-26 18:35 ` Christoph Lameter 2015-01-27 10:52 ` Michal Hocko 2015-01-27 10:52 ` Michal Hocko 2015-01-27 16:59 ` Christoph Lameter 2015-01-27 16:59 ` Christoph Lameter 2015-01-30 15:28 ` Michal Hocko 2015-01-30 15:28 ` Michal Hocko 2015-01-26 17:28 ` Michal Hocko 2015-01-26 17:28 ` Michal Hocko 2015-01-26 18:35 ` Christoph Lameter 2015-01-26 18:35 ` Christoph Lameter 2015-01-26 22:11 ` Andrew Morton 2015-01-26 22:11 ` Andrew Morton 2015-01-27 10:41 ` Michal Hocko 2015-01-27 10:41 ` Michal Hocko 2015-01-27 10:33 ` Vinayak Menon 2015-01-27 10:33 ` Vinayak Menon 2015-01-27 10:45 ` Michal Hocko 2015-01-27 10:45 ` Michal Hocko 2015-01-29 17:32 ` Christoph Lameter 2015-01-29 17:32 ` Christoph Lameter 2015-01-30 15:27 ` Michal Hocko 2015-01-30 15:27 ` Michal Hocko 2015-01-16 1:17 ` Andrew Morton 2015-01-16 1:17 ` Andrew Morton 2015-01-16 5:10 ` Vinayak Menon 2015-01-16 5:10 ` Vinayak Menon 2015-01-17 16:29 ` Vinayak Menon 2015-01-17 16:29 ` Vinayak Menon 2015-02-11 22:14 ` Andrew Morton 2015-02-11 22:14 ` Andrew Morton 2015-02-12 16:19 ` Vlastimil Babka 2015-02-12 16:19 ` Vlastimil Babka
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=alpine.DEB.2.11.1501261233550.16786@gentwo.org \ --to=cl@linux.com \ --cc=akpm@linux-foundation.org \ --cc=hannes@cmpxchg.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mgorman@suse.de \ --cc=mhocko@suse.cz \ --cc=minchan@kernel.org \ --cc=vdavydov@parallels.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: 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.