linux-kernel - Re: [PATCH 1/1] cputime: Make the reported utime+stime correspond to the actual runtime.

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, 30 Jun 2015 14:18:12 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Fredrik Markström <fredrik.markstrom@...il.com>
Cc:	mingo@...hat.com, linux-kernel@...r.kernel.org,
	Rik van Riel <riel@...hat.com>,
	Jason Low <jason.low2@...com>,
	Frédéric Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCH 1/1] cputime: Make the reported utime+stime correspond to
 the actual runtime.

On Tue, Jun 30, 2015 at 01:50:15PM +0200, Fredrik Markström wrote:
> Excellent,

Please do not top post.

> The reason I replaced the early bail with that last test is that I
> believe it needs to be done within the lock and I wanted to keep that
> region short. To be honest I'm not sure this test is needed at all
> anymore, but I couldn't make sense of the comment above the early bail
> so I didn't dare to remove it.

Ah, there's a simple reason we should keep it, apart from the wobblies
in calculating the division. Imagine two concurrent callers, on with an
rtime ahead of the other. Let the latest rtime caller acquire the lock
first and compute s/u-time. Once the second caller acquires the lock, we
observe the last rtime was in the past and we use the latest values.

> Regarding the lock, have you considered how many cores you need
> hammering at rusage to introduce some substantial congestion ? 

Spinlock contention across 120 cores and 4 nodes is pretty bad, even
with hardly any hold time :-)

I've not investigated where the absolute pain threshold is, but given the
size (and growth) of machines these days, its seems like a prudent
thing.

> Sorry for not letting this go (I know I should) but I always feel bad
> introducing per thread data.

Yes agreed, but a global lock is just asking for trouble. Esp when its
as easy as this to avoid it.

--
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/