From: Frederic Weisbecker <fweisbec@gmail.com>
To: Christoph Lameter <cl@gentwo.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Gilad Ben-Yossef <gilad@benyossef.com>,
Thomas Gleixner <tglx@linutronix.de>, Tejun Heo <tj@kernel.org>,
John Stultz <johnstul@us.ibm.com>,
Mike Frysinger <vapier@gentoo.org>,
Minchan Kim <minchan.kim@gmail.com>,
Hakan Akkan <hakanakkan@gmail.com>,
Max Krasnyansky <maxk@qualcomm.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
hughd@google.com, viresh.kumar@linaro.org, hpa@zytor.com,
mingo@kernel.org, peterz@infradead.org
Subject: Re: vmstat: On demand vmstat workers V5
Date: Thu, 29 May 2014 02:36:11 +0200 [thread overview]
Message-ID: <20140529003609.GG6507@localhost.localdomain> (raw)
In-Reply-To: <alpine.DEB.2.10.1405281110210.22514@gentwo.org>
On Wed, May 28, 2014 at 11:19:49AM -0500, Christoph Lameter wrote:
> On Wed, 28 May 2014, Frederic Weisbecker wrote:
>
> > On Mon, May 12, 2014 at 01:18:10PM -0500, Christoph Lameter wrote:
> > > #ifdef CONFIG_SMP
> > > static DEFINE_PER_CPU(struct delayed_work, vmstat_work);
> > > int sysctl_stat_interval __read_mostly = HZ;
> > > +static DECLARE_BITMAP(cpu_stat_off_bits, CONFIG_NR_CPUS) __read_mostly;
> > > +const struct cpumask *const cpu_stat_off = to_cpumask(cpu_stat_off_bits);
> > > +EXPORT_SYMBOL(cpu_stat_off);
> >
> > Is there no way to make it a cpumask_var_t, and allocate it from
> > start_shepherd_timer()?
> >
> > This should really take less space overall.
>
> This was taken from the way things work with the other cpumasks in
> linux/kernel/cpu.c. Its compatible with the way done there and allows
> also the write protection of the cpumask outside of vmstat.c
The cpumasks in cpu.c are special as they are the base of the cpumask_var_t
definition. They are necessary to define nr_cpu_bits which is the base of
cpumask_var_t allocations. As such they must stay lower level and defined
on top of NR_CPUS.
But most other cases don't need that huge static bitmap. I actually haven't
seen any other struct cpumask than isn't based on cpumask_var_t.
>
> > > + schedule_delayed_work(this_cpu_ptr(&vmstat_work),
> > > + __round_jiffies_relative(sysctl_stat_interval,
> > > + HOUSEKEEPING_CPU));
> >
> > Maybe you can just make the shepherd work unbound and let bind it from userspace
> > once we have the workqueue user affinity patchset in.
>
> Yes that is what V5 should have done. Looks like the final version was not
> posted. Sigh. The correct patch follows this message and it no longer uses
> HOUSEKEEPING_CPU.
Ok.
>
>
> > OTOH, it means you need to have a vmstat_update work on the housekeeping CPU as well.
>
> Well the vnstat_udpate may not be needed on the processor where the
> shepherd runs so it may save something.
Ok, thanks!
>
> From cl@linux.com Thu Oct 3 12:41:21 2013
> Date: Thu, 3 Oct 2013 12:41:21 -0500 (CDT)
> From: Christoph Lameter <cl@linux.com>
> To: Andrew Morton <akpm@linux-foundation.org>
> Cc: Gilad Ben-Yossef <gilad@benyossef.com>, Thomas Gleixner <tglx@linutronix.de>, Tejun Heo <tj@kernel.org>, John Stultz <johnstul@us.ibm.com>, Mike Frysinger <vapier@gentoo.org>, Minchan Kim <minchan.kim@gmail.com>, Hakan Akkan <hakanakkan@gmail.com>, Max Krasnyansky <maxk@qualcomm.com>, Frederic Weisbecker <fweisbec@gmail.com>, Paul E. McKenney <paulmck@linux.vnet.ibm.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, hughd@google.com, viresh.kumar@linaro.org, hpa@zytor.com, mingo@kernel.org, peterz@infradead.org
> Subject: vmstat: On demand vmstat workers V6
Please post it on a new thread so it gets noticed by others.
Thanks.
--
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: Frederic Weisbecker <fweisbec@gmail.com>
To: Christoph Lameter <cl@gentwo.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Gilad Ben-Yossef <gilad@benyossef.com>,
Thomas Gleixner <tglx@linutronix.de>, Tejun Heo <tj@kernel.org>,
John Stultz <johnstul@us.ibm.com>,
Mike Frysinger <vapier@gentoo.org>,
Minchan Kim <minchan.kim@gmail.com>,
Hakan Akkan <hakanakkan@gmail.com>,
Max Krasnyansky <maxk@qualcomm.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
hughd@google.com, viresh.kumar@linaro.org, hpa@zytor.com,
mingo@kernel.org, peterz@infradead.org
Subject: Re: vmstat: On demand vmstat workers V5
Date: Thu, 29 May 2014 02:36:11 +0200 [thread overview]
Message-ID: <20140529003609.GG6507@localhost.localdomain> (raw)
In-Reply-To: <alpine.DEB.2.10.1405281110210.22514@gentwo.org>
On Wed, May 28, 2014 at 11:19:49AM -0500, Christoph Lameter wrote:
> On Wed, 28 May 2014, Frederic Weisbecker wrote:
>
> > On Mon, May 12, 2014 at 01:18:10PM -0500, Christoph Lameter wrote:
> > > #ifdef CONFIG_SMP
> > > static DEFINE_PER_CPU(struct delayed_work, vmstat_work);
> > > int sysctl_stat_interval __read_mostly = HZ;
> > > +static DECLARE_BITMAP(cpu_stat_off_bits, CONFIG_NR_CPUS) __read_mostly;
> > > +const struct cpumask *const cpu_stat_off = to_cpumask(cpu_stat_off_bits);
> > > +EXPORT_SYMBOL(cpu_stat_off);
> >
> > Is there no way to make it a cpumask_var_t, and allocate it from
> > start_shepherd_timer()?
> >
> > This should really take less space overall.
>
> This was taken from the way things work with the other cpumasks in
> linux/kernel/cpu.c. Its compatible with the way done there and allows
> also the write protection of the cpumask outside of vmstat.c
The cpumasks in cpu.c are special as they are the base of the cpumask_var_t
definition. They are necessary to define nr_cpu_bits which is the base of
cpumask_var_t allocations. As such they must stay lower level and defined
on top of NR_CPUS.
But most other cases don't need that huge static bitmap. I actually haven't
seen any other struct cpumask than isn't based on cpumask_var_t.
>
> > > + schedule_delayed_work(this_cpu_ptr(&vmstat_work),
> > > + __round_jiffies_relative(sysctl_stat_interval,
> > > + HOUSEKEEPING_CPU));
> >
> > Maybe you can just make the shepherd work unbound and let bind it from userspace
> > once we have the workqueue user affinity patchset in.
>
> Yes that is what V5 should have done. Looks like the final version was not
> posted. Sigh. The correct patch follows this message and it no longer uses
> HOUSEKEEPING_CPU.
Ok.
>
>
> > OTOH, it means you need to have a vmstat_update work on the housekeeping CPU as well.
>
> Well the vnstat_udpate may not be needed on the processor where the
> shepherd runs so it may save something.
Ok, thanks!
>
> From cl@linux.com Thu Oct 3 12:41:21 2013
> Date: Thu, 3 Oct 2013 12:41:21 -0500 (CDT)
> From: Christoph Lameter <cl@linux.com>
> To: Andrew Morton <akpm@linux-foundation.org>
> Cc: Gilad Ben-Yossef <gilad@benyossef.com>, Thomas Gleixner <tglx@linutronix.de>, Tejun Heo <tj@kernel.org>, John Stultz <johnstul@us.ibm.com>, Mike Frysinger <vapier@gentoo.org>, Minchan Kim <minchan.kim@gmail.com>, Hakan Akkan <hakanakkan@gmail.com>, Max Krasnyansky <maxk@qualcomm.com>, Frederic Weisbecker <fweisbec@gmail.com>, Paul E. McKenney <paulmck@linux.vnet.ibm.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, hughd@google.com, viresh.kumar@linaro.org, hpa@zytor.com, mingo@kernel.org, peterz@infradead.org
> Subject: vmstat: On demand vmstat workers V6
Please post it on a new thread so it gets noticed by others.
Thanks.
next prev parent reply other threads:[~2014-05-29 0:36 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-12 18:18 vmstat: On demand vmstat workers V5 Christoph Lameter
2014-05-12 18:18 ` Christoph Lameter
2014-05-13 15:24 ` Thomas Gleixner
2014-05-13 15:24 ` Thomas Gleixner
2014-05-14 16:07 ` Christoph Lameter
2014-05-14 16:07 ` Christoph Lameter
2014-05-14 23:15 ` Thomas Gleixner
2014-05-14 23:15 ` Thomas Gleixner
2014-05-27 20:07 ` Christoph Lameter
2014-05-27 20:07 ` Christoph Lameter
2014-05-28 15:21 ` Frederic Weisbecker
2014-05-28 15:21 ` Frederic Weisbecker
2014-05-28 16:19 ` Christoph Lameter
2014-05-28 16:19 ` Christoph Lameter
2014-05-29 0:36 ` Frederic Weisbecker [this message]
2014-05-29 0:36 ` Frederic Weisbecker
2014-05-29 14:07 ` Christoph Lameter
2014-05-29 14:07 ` Christoph Lameter
2014-05-29 14:26 ` Frederic Weisbecker
2014-05-29 14:26 ` Frederic Weisbecker
2014-05-29 16:24 ` Christoph Lameter
2014-05-29 16:24 ` Christoph Lameter
2014-05-29 16:40 ` Paul E. McKenney
2014-05-29 16:40 ` Paul E. McKenney
2014-05-29 16:29 ` Paul E. McKenney
2014-05-29 16:29 ` Paul E. McKenney
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=20140529003609.GG6507@localhost.localdomain \
--to=fweisbec@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@gentwo.org \
--cc=gilad@benyossef.com \
--cc=hakanakkan@gmail.com \
--cc=hpa@zytor.com \
--cc=hughd@google.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=maxk@qualcomm.com \
--cc=minchan.kim@gmail.com \
--cc=mingo@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=vapier@gentoo.org \
--cc=viresh.kumar@linaro.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.