Skip to contentSkip to conversation

vmstat kthreads

PATCH In review Paul E. McKenney 4 participants 19 messages Jun 18, 2013 – Aug 28, 2013

Subsystems (3)
Memory management MM core Proc sysctl
lore
Share & tools
lore

Paul E. McKenney

author
#0 lore raw

Hello!

I have been digging around the vmstat kthreads a bit, and it appears to me that there is no reason to run a given CPU's vmstat kthread unless that CPU spends some time executing in the kernel. If correct, this observation indicates that one way to safely reduce OS jitter due to the vmstat kthreads is to prevent them from executing on a given CPU if that CPU has been executing in usermode since the last time that this CPU's vmstat kthread executed.

Does this seem like a sensible course of action, or did I miss something when I went through the code?

Thanx, Paul

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

#1 lore raw
Quoted 7 lines · Paul E. McKenney

I have been digging around the vmstat kthreads a bit, and it appears to me that there is no reason to run a given CPU's vmstat kthread unless that CPU spends some time executing in the kernel. If correct, this observation indicates that one way to safely reduce OS jitter due to the vmstat kthreads is to prevent them from executing on a given CPU if that CPU has been executing in usermode since the last time that this CPU's vmstat kthread executed.

Right and we have patches to that effect.

Quoted 2 lines

Does this seem like a sensible course of action, or did I miss something when I went through the code?

Nope you are right on.

Gilad Ben-Yossef has been posting patches that address this issue in Feb 2012. Ccing him. Can we see your latest work, Gilead?

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

author
#2 lore raw
Quoted 11 lines · Christoph Lameter
Quoted 7 lines · Paul E. McKenney

I have been digging around the vmstat kthreads a bit, and it appears to me that there is no reason to run a given CPU's vmstat kthread unless that CPU spends some time executing in the kernel. If correct, this observation indicates that one way to safely reduce OS jitter due to the vmstat kthreads is to prevent them from executing on a given CPU if that CPU has been executing in usermode since the last time that this CPU's vmstat kthread executed.

Right and we have patches to that effect.

Even better!

Quoted 7 lines
Quoted 2 lines

Does this seem like a sensible course of action, or did I miss something when I went through the code?

Nope you are right on.

Gilad Ben-Yossef has been posting patches that address this issue in Feb 2012. Ccing him. Can we see your latest work, Gilead?

Is it this one?

https://lkml.org/lkml/2012/5/3/269

Thanx, Paul

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

#3 lore raw
Quoted 6 lines · Paul E. McKenney
Quoted 2 lines

Gilad Ben-Yossef has been posting patches that address this issue in Feb 2012. Ccing him. Can we see your latest work, Gilead?

Is it this one?

https://lkml.org/lkml/2012/5/3/269

Yes that is it. Maybe the scheme there could be generalized so that other subsystems can also use this to disable their threads if nothing is going on? Or integrate the monitoring into the notick logic somehow?

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

#4 lore raw
Quoted 5 lines · Christoph Lameter
Quoted 3 lines · Paul E. McKenney
Quoted 2 lines

Gilad Ben-Yossef has been posting patches that address this issue in Feb 2012. Ccing him. Can we see your latest work, Gilead?

Quoted 8 lines
Quoted 3 lines

Is it this one?

https://lkml.org/lkml/2012/5/3/269

Yes that is it. Maybe the scheme there could be generalized so that other subsystems can also use this to disable their threads if nothing is going on? Or integrate the monitoring into the notick logic somehow?

I respinned the original patch based on feedback from Christoph for 3.2 and even did some light testing then, but got distracted and never posted the result.

I've just ported them over to 3.10 and they merge (with a small fix due to deferred workqueue API changes) and build. I did not try to run this version though.
I'll post them as replies to this message.

I'd be happy to rescue them from the "TODO" pile... :-)

Signature · 16 lines
Gilad Ben-Yossef
Chief Coffee Drinker
[email protected]
Israel Cell: +972-52-8260388
US Cell: +1-973-8260388
http://benyossef.com

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
#5 lore raw
Quoted 15 lines · Gilad Ben-Yossef
Quoted 5 lines · Christoph Lameter
Quoted 3 lines · Paul E. McKenney
Quoted 2 lines

Gilad Ben-Yossef has been posting patches that address this issue in Feb 2012. Ccing him. Can we see your latest work, Gilead?

Quoted 8 lines
Quoted 3 lines

Is it this one?

https://lkml.org/lkml/2012/5/3/269

Yes that is it. Maybe the scheme there could be generalized so that other subsystems can also use this to disable their threads if nothing is going on? Or integrate the monitoring into the notick logic somehow?

Quoted 8 lines

I respinned the original patch based on feedback from Christoph for 3.2 and even did some light testing then, but got distracted and never posted the result.

I've just ported them over to 3.10 and they merge (with a small fix due to deferred workqueue API changes) and build. I did not try to run this version though.
I'll post them as replies to this message.

... or rather, I'll send them later this evening when I'm not behind a firewall that is blocking SMTP connections... :-)

Gilad

Quoted 14 lines

I'd be happy to rescue them from the "TODO" pile... :-)

--
Gilad Ben-Yossef
Chief Coffee Drinker
[email protected]
Israel Cell: +972-52-8260388
US Cell: +1-973-8260388
http://benyossef.com

"If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?"
-- Jean-Baptiste Queru

Signature · 16 lines
Gilad Ben-Yossef
Chief Coffee Drinker
[email protected]
Israel Cell: +972-52-8260388
US Cell: +1-973-8260388
http://benyossef.com

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
#6 lore raw
Quoted 5 lines · Gilad Ben-Yossef
Quoted 1 line

I'll post them as replies to this message.

... or rather, I'll send them later this evening when I'm not behind a firewall that is blocking SMTP connections... :-)

Well, I must have botched the reply-to header, so they ended up as a separate message post:

https://lkml.org/lkml/2013/6/19/583
https://lkml.org/lkml/2013/6/19/580

Signature · 16 lines
Gilad Ben-Yossef
Chief Coffee Drinker
[email protected]
Israel Cell: +972-52-8260388
US Cell: +1-973-8260388
http://benyossef.com

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
author
#7 lore raw
In reply to Gilad Ben-Yossef
Quoted 19 lines · Gilad Ben-Yossef
Quoted 5 lines · Christoph Lameter
Quoted 3 lines · Paul E. McKenney
Quoted 2 lines

Gilad Ben-Yossef has been posting patches that address this issue in Feb 2012. Ccing him. Can we see your latest work, Gilead?

Quoted 8 lines
Quoted 3 lines

Is it this one?

https://lkml.org/lkml/2012/5/3/269

Yes that is it. Maybe the scheme there could be generalized so that other subsystems can also use this to disable their threads if nothing is going on? Or integrate the monitoring into the notick logic somehow?

I respinned the original patch based on feedback from Christoph for 3.2 and even did some light testing then, but got distracted and never posted the result.

Quoted 6 lines

I've just ported them over to 3.10 and they merge (with a small fix due to deferred workqueue API changes) and build. I did not try to run this version though.
I'll post them as replies to this message.

I'd be happy to rescue them from the "TODO" pile... :-)

Please! ;-)

Thanx, Paul

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

#8 lore raw
Quoted 8 lines · Paul E. McKenney
Quoted 6 lines

I've just ported them over to 3.10 and they merge (with a small fix due to deferred workqueue API changes) and build. I did not try to run this version though.
I'll post them as replies to this message.

I'd be happy to rescue them from the "TODO" pile... :-)

Please! ;-)

Well if we are going into vmstat mods then I'd also like to throw in this old patch:

Subject: vmstat: Avoid interrupt disable in vm stats loop

There is no need to disable interrupts if we use xchg().

Signed-off-by Christoph Lameter <[email protected]>
mm/vmstat.c +1 -6
Index: linux/mm/vmstat.c
===================================================================
@@ -445,13 +445,8 @@ void refresh_cpu_vm_stats(int cpu)
 
 		for (i = 0; i < NR_VM_ZONE_STAT_ITEMS; i++)
 			if (p->vm_stat_diff[i]) {
-				unsigned long flags;
-				int v;
+				int v = xchg(p->vm_stat_diff + i, 0);
 
-				local_irq_save(flags);
-				v = p->vm_stat_diff[i];
-				p->vm_stat_diff[i] = 0;
-				local_irq_restore(flags);
 				atomic_long_add(v, &zone->vm_stat[i]);
 				global_diff[i] += v;
 #ifdef CONFIG_NUMA

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

#9 lore raw

PATCH v2 1/2 mm: make vmstat_update periodic run conditional

In reply to Gilad Ben-Yossef

vmstat_update runs every second from the work queue to update statistics and drain per cpu pages back into the global page allocator.

This is useful in most circumstances but is wasteful if the CPU doesn't actually make any VM activity. This can happen in the situtation that the CPU is idle or running a CPU bound long term task (e.g. CPU isolation), in which case the periodic vmstate_update timer needlessly interrupts the CPU.

This patch tries to make vmstat_update schedule itself for the next round only if there was any work for it to do in the previous run. The assumption is that if for a whole second we didn't see any VM activity it is reasnoable to assume that the CPU is not using the VM because it is idle or runs a long term single CPU bound task.

A scapegoat CPU is picked to serve to periodically monitor CPUs that have their vmstat_update work stopped and re-schedule them if VM activity is detected. The scapegoat CPU never stops its vmstat_update work item instance.

Signed-off-by Gilad Ben-Yossef <[email protected]>
CC Christoph Lameter <[email protected]>
CC Paul E. McKenney <[email protected]>
CC [email protected]
CC [email protected]
---
 include/linux/vmstat.h |    2 +-
 mm/vmstat.c            |   92 ++++++++++++++++++++++++++++++++++++++++-------
 2 files changed, 79 insertions(+), 15 deletions(-)
include/linux/vmstat.h +1 -1
index c586679..a30ab79 100644
@@ -198,7 +198,7 @@ extern void __inc_zone_state(struct zone *, enum zone_stat_item);
 extern void dec_zone_state(struct zone *, enum zone_stat_item);
 extern void __dec_zone_state(struct zone *, enum zone_stat_item);
 
-void refresh_cpu_vm_stats(int);
+bool refresh_cpu_vm_stats(int);
 void refresh_zone_stat_thresholds(void);
 
 void drain_zonestat(struct zone *zone, struct per_cpu_pageset *);
mm/vmstat.c +78 -14

158 lines not on this page · raw message

Signature · 7 lines
1.7.0.4

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
#10 lore raw

Re: [PATCH v2 1/2] mm: make vmstat_update periodic run conditional

Quoted 4 lines · Gilad Ben-Yossef
mm/vmstat.c +4 -0
+static void vmstat_update(struct work_struct *w)
+{
+	int cpu, this_cpu = smp_processor_id();
+

mm/vmstat.c static const struct file_operations proc_vmstat_file_operations = { · line 1244

Quoted 10 lines
mm/vmstat.c +10 -0
+	if (unlikely(this_cpu == vmstat_monitor_cpu))
+		for_each_cpu_not(cpu, &vmstat_cpus)
+			if (need_vmstat(cpu))
+				start_cpu_timer(cpu);
+
+	if (likely(refresh_cpu_vm_stats(this_cpu) || (this_cpu == vmstat_monitor_cpu)))
+		schedule_delayed_work(&__get_cpu_var(vmstat_work),
+				round_jiffies_relative(sysctl_stat_interval));
+	else
+		cpumask_clear_cpu(this_cpu, &vmstat_cpus);

The clearing of vmstat_cpus could be avoided if this processor is not running tickless. Frequent updates to vmstat_cpus could become an issue.

Quoted 4 lines
mm/vmstat.c +1 -2
 	case CPU_DOWN_PREPARE_FROZEN:
-		cancel_delayed_work_sync(&per_cpu(vmstat_work, cpu));
-		per_cpu(vmstat_work, cpu).work.func = NULL;
+		if (cpumask_test_cpu(cpu, &vmstat_cpus)) {

mm/vmstat.c static int __cpuinit vmstat_cpuup_callback(struct notifier_block *nfb, · line 1276

Quoted 10 lines
mm/vmstat.c +9 -0
+			cancel_delayed_work_sync(&per_cpu(vmstat_work, cpu));
+			per_cpu(vmstat_work, cpu).work.func = NULL;
+			if(cpu == vmstat_monitor_cpu) {
+				int this_cpu = smp_processor_id();
+				vmstat_monitor_cpu = this_cpu;
+				if (!cpumask_test_cpu(this_cpu, &vmstat_cpus))
+					start_cpu_timer(this_cpu);
+			}
+		}
 		break;

If the disabling of vmstat is tied into the nohz logic then these portions are no longer necessary.

mm/vmstat.c static int __init setup_vmstat(void) · line 1303

Quoted 6 lines
mm/vmstat.c +2 -0
@@ -1237,8 +1299,10 @@ static int __init setup_vmstat(void)
 
 	register_cpu_notifier(&vmstat_notifier);
 
+	vmstat_monitor_cpu = smp_processor_id();
+

Drop the vmstat_monitor_cpu and use the dynticks processor.

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

#12 lore raw

Re: [PATCH v2 1/2] mm: make vmstat_update periodic run conditional

Quoted 2 lines · Christoph Lameter

Is there any work in progress on this issue?

Sorry, I dropped the ball following up on this one. Let me check up on it now...

Gilad

Signature · 10 lines
Gilad Ben-Yossef
Chief Coffee Drinker
[email protected]
Israel Cell: +972-52-8260388
US Cell: +1-973-8260388
http://benyossef.com

"If you take a class in large-scale robotics, can you end up in a situation
where the homework eats your dog?"
 -- Jean-Baptiste Queru
#13 lore raw

Re: [PATCH v2 1/2] mm: make vmstat_update periodic run conditional

In reply to Christoph Lameter
Quoted 14 lines · Christoph Lameter
Quoted 11 lines · Gilad Ben-Yossef
mm/vmstat.c +10 -0
+static void vmstat_update(struct work_struct *w)
+{
+     int cpu, this_cpu = smp_processor_id();
+
+     if (unlikely(this_cpu == vmstat_monitor_cpu))
+             for_each_cpu_not(cpu, &vmstat_cpus)
+                     if (need_vmstat(cpu))
+                             start_cpu_timer(cpu);
+
+     if (likely(refresh_cpu_vm_stats(this_cpu) || (this_cpu ==

vmstat_monitor_cpu)))

Quoted 8 lines

mm/vmstat.c static const struct file_operations proc_vmstat_file_operations = { · line 1244

Quoted 5 lines
mm/vmstat.c +2 -0
+             schedule_delayed_work(&__get_cpu_var(vmstat_work),
+

round_jiffies_relative(sysctl_stat_interval));

mm/vmstat.c +2 -0
+     else
+             cpumask_clear_cpu(this_cpu, &vmstat_cpus);

The clearing of vmstat_cpus could be avoided if this processor is not running tickless. Frequent updates to vmstat_cpus could become an issue.

I like the idea of tying the vmstat disabling to the tickless logic but I seem to have run
into a bit of a chicken and egg problem here:

vmstat_update runs from the vmstat work queue item by the workqueue kernel thread.

If this code is running, it means there are at least two schedulable tasks:
1. The workqueue kernel thread, because it is running.
2. At least one more task, otherwise were were in idle and the workqueue kernel thread
would not execute this work item.

Unfortunately, having two schedulable tasks means we're not running tickless, so the check
will never trigger - or have I've missed something obvious?

Thanks,
Gilad

--
Gilad Ben-Yossef
Chief Coffee Drinker
[email protected]
Israel Cell: +972-52-8260388
US Cell: +1-973-8260388
http://benyossef.com

"If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?"
-- Jean-Baptiste Queru

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

#14 lore raw

Re: [PATCH v2 1/2] mm: make vmstat_update periodic run conditional

Quoted 9 lines · Gilad Ben-Yossef

vmstat_update runs from the vmstat work queue item by the workqueue kernel thread.

If this code is running, it means there are at least two schedulable tasks:
1. The workqueue kernel thread, because it is running.
2. At least one more task, otherwise were were in idle and the workqueue kernel thread
would not execute this work item.

Quoted 3 lines

Unfortunately, having two schedulable tasks means we're not running tickless, so the check
will never trigger - or have I've missed something obvious?

The vmstat update is deferrable work. As such it is not required to run and can be pushed off. It will not be considered for the calculation of the next timer interupt. See __next_timer_interrupt().

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

#15 lore raw

Re: [PATCH v2 1/2] mm: make vmstat_update periodic run conditional

Quoted 11 lines · Christoph Lameter
Quoted 9 lines · Gilad Ben-Yossef

vmstat_update runs from the vmstat work queue item by the workqueue kernel thread.

If this code is running, it means there are at least two schedulable tasks:
1. The workqueue kernel thread, because it is running.
2. At least one more task, otherwise were were in idle and the workqueue kernel thread
would not execute this work item.

Quoted 7 lines
Quoted 3 lines

Unfortunately, having two schedulable tasks means we're not running tickless, so the check
will never trigger - or have I've missed something obvious?

The vmstat update is deferrable work. As such it is not required to run and can be pushed off. It will not be considered for the calculation of the next timer interupt. See __next_timer_interrupt().

Yes, I understand that. I was trying to say something else:

If the code does not consider setting the vmstat_cpus bit in the mask unless we are running
on a CPU in tickless state, than we will (almost) never set vmstat_cpus since we will (almost)
never be tickless in a deferrable work -

If there is no other task, we will be in idle and the deferreable work will not be scheduled since the timer will not fire.

If there is one task originally, the work queue gets executed in the work queue kernel thread, so we have two tasks so tickless will disengae.

If there is more than one task tickless is not engage.

Bottom line - we will be in active tickless mode when running a deferreable work item only if we happen to have fire the timer that scheduled the work and the previously running task happened to block. This is rare enough that in practice we will almost never be in active tickless mode when running the vmstat_update function.

I hope I manage to explain myself better this time.

Thanks,
Gilad

Signature · 16 lines
Gilad Ben-Yossef
Chief Coffee Drinker
[email protected]
Israel Cell: +972-52-8260388
US Cell: +1-973-8260388
http://benyossef.com

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
#16 lore raw

Re: [PATCH v2 1/2] mm: make vmstat_update periodic run conditional

Quoted 5 lines · Gilad Ben-Yossef

If the code does not consider setting the vmstat_cpus bit in the mask unless we are running
on a CPU in tickless state, than we will (almost) never set vmstat_cpus since we will (almost)
never be tickless in a deferrable work -

Sorry never got around to answering this one. Not sure what to do about it.

How about this: Disable the vmstats when there is no diff to handle instead? This means that the OS was quiet during the earlier period. That way you have an independent criteria for switching vmstat work off from tickless. Would even work when there are multiple processes running on the processor if none of them causes counter updates.

In the meantime there are additional patches for the vmstat function pending for merge from me (not related to the conditional running of vmstat but may make it easier to implement). So if you want to do any work then please on top of the newer release available from Andrew's tree.

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

#17 lore raw

PATCH v2 2/2 mm: add sysctl to pick vmstat monitor cpu

In reply to Gilad Ben-Yossef

Add a sysctl knob to enable admin to hand pick the scapegoat cpu that will perform the extra work of preiodically checking for new VM activity on CPUs that have switched off their vmstat_update work item schedling.

Signed-off-by Gilad Ben-Yossef <[email protected]>
CC Christoph Lameter <[email protected]>
CC Paul E. McKenney <[email protected]>
CC [email protected]
CC [email protected]
---
 include/linux/vmstat.h |    1 +
 kernel/sysctl.c        |    7 ++++
 mm/vmstat.c            |   72 ++++++++++++++++++++++++++++++++++++++++++++----
 3 files changed, 74 insertions(+), 6 deletions(-)
include/linux/vmstat.h +1 -0
index a30ab79..470f1d0 100644
@@ -9,6 +9,7 @@
 #include <linux/atomic.h>
 
 extern int sysctl_stat_interval;
+extern int sysctl_vmstat_monitor_cpu;
 
 #ifdef CONFIG_VM_EVENT_COUNTERS
 /*
kernel/sysctl.c +7 -0
index 9edcf45..58c889e 100644
@@ -1361,6 +1361,13 @@ static struct ctl_table vm_table[] = {
 		.mode		= 0644,
 		.proc_handler	= proc_dointvec_jiffies,
 	},
+	{
+		.procname	= "stat_monitor_cpu",
+		.data		= &sysctl_vmstat_monitor_cpu,
+		.maxlen		= sizeof(sysctl_vmstat_monitor_cpu),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec,
+	},
 #endif
 #ifdef CONFIG_MMU
 	{
mm/vmstat.c +66 -6

106 lines not on this page · raw message

Signature · 7 lines
1.7.0.4

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
#18 lore raw

Re: [PATCH v2 2/2] mm: add sysctl to pick vmstat monitor cpu

Quoted 4 lines · Gilad Ben-Yossef

Add a sysctl knob to enable admin to hand pick the scapegoat cpu that will perform the extra work of preiodically checking for new VM activity on CPUs that have switched off their vmstat_update work item schedling.

Not necessary if we use the dynticks sacrificial processor (boot cpu). Seems to be also used for RCU.

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