linux-kernel - Re: [PATCH v1 5/6] mm: make vmstat

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 8 May 2012 18:18:44 +0300
From:	Gilad Ben-Yossef <gilad@...yossef.com>
To:	Christoph Lameter <cl@...ux.com>
Cc:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Tejun Heo <tj@...nel.org>, John Stultz <johnstul@...ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Mel Gorman <mel@....ul.ie>, Mike Frysinger <vapier@...too.org>,
	David Rientjes <rientjes@...gle.com>,
	Hugh Dickins <hughd@...gle.com>,
	Minchan Kim <minchan.kim@...il.com>,
	Konstantin Khlebnikov <khlebnikov@...nvz.org>,
	Chris Metcalf <cmetcalf@...era.com>,
	Hakan Akkan <hakanakkan@...il.com>,
	Max Krasnyansky <maxk@...lcomm.com>,
	Frederic Weisbecker <fweisbec@...il.com>, linux-mm@...ck.org
Subject: Re: [PATCH v1 5/6] mm: make vmstat_update periodic run conditional

On Mon, May 7, 2012 at 6:29 PM, Christoph Lameter <cl@...ux.com> wrote:
> On Thu, 3 May 2012, Gilad Ben-Yossef wrote:
>
>> vmstat_update runs every second from the work queue to update statistics
>> and drain per cpu pages back into the global page allocator.
>
> Looks good.

Thanks :-)

>
> - vmstat_off_cpus is a bit strange. Could we have a cpumask that has a bit
> set if vmstat is active? Rename to "vmstat_cpus"?

Sure.

> - Start out with vmstat_cpus cleared? Cpus only need vmstat if they do
> something and if a cpu is idle on boot then it will not need vmstat
> enabled until the cpu does something useful.

Ah cool. I haven't thought of that.

>
>> @@ -1204,8 +1265,14 @@ static int __init setup_vmstat(void)
>>
>>       register_cpu_notifier(&vmstat_notifier);
>>
>> +     INIT_DELAYED_WORK_DEFERRABLE(&vmstat_monitor_work,
>> +                             vmstat_update_monitor);
>> +     queue_delayed_work(system_unbound_wq,
>> +                             &vmstat_monitor_work,
>> +                             round_jiffies_relative(HZ));
>> +
>>       for_each_online_cpu(cpu)
>> -             start_cpu_timer(cpu);
>> +             setup_cpu_timer(cpu);
>>  #endif
>>  #ifdef CONFIG_PROC_FS
>>       proc_create("buddyinfo", S_IRUGO, NULL, &fragmentation_file_operations);
>
> So the monitoring thread just bounces around the system? Hope that the
> scheduler does the right thing to keep it on processors that do some other
> work.

My line of thought was that if we explicitly choose a scapegoat cpu we
and the user
need to manage this - such as worry about what happens if the
scapegoats is offlines and
let the user explicitly  designate the scapegoat cpu thus creating
another knob, and worrying
about what happens if the user designate such a cpu but then it goes offlines...

I figured the user needs to worry about other unbounded work items
anyway if he cares about
where such things are run in the general case, but using isolcpus for example.

The same should be doable with cpusets, except that right now we mark
unbounded workqueue
worker threads as pinned even though they aren't. If I understood the
discussion, the idea is
exactly to stop users from putting these threads in non root cpusets.
I am not 100% sure why..

Does that makes sense?

Thanks!
Gilad

Gilad


-- 
Gilad Ben-Yossef
Chief Coffee Drinker
gilad@...yossef.com
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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/