linux-kernel - Re: regression introduced by - timers: fix itimer/many thread hang

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]

Message-ID: <Pine.LNX.4.64.0811100834500.21257@quilx.com>
Date:	Mon, 10 Nov 2008 08:38:42 -0600 (CST)
From:	Christoph Lameter <cl@...ux-foundation.org>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	Frank Mayhar <fmayhar@...gle.com>,
	Doug Chapman <doug.chapman@...com>, mingo@...e.hu,
	roland@...hat.com, adobriyan@...il.com, akpm@...ux-foundation.org,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: regression introduced by - timers: fix itimer/many thread hang

On Fri, 7 Nov 2008, Peter Zijlstra wrote:

> The advantage is that the memory foot-print scales with nr_tasks and the
> runtime cost is min(nr_tasks, nr_cpus) where nr_cpus is limited to the
> cpus the process actually runs on, so this takes full advantage of
> things like cpusets.

Typically you want threads of a process to spread out as far as possible.
The point of having multiple threads is concurrency after all. So this
will deteriorate in the common cases where you want the full aggregate
processing power of a machine to work on something. Timer processing is
already a latency problem (isnt there some option to switch that off?) and
a solution like this is going to make things worse.

Can we at least somehow make sure that nothing significantly happens in a
timer interrupt on a processor if the thread has not scheduled any events
or not odone any system calls?
--
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/