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]

Message-ID: <CAKdL+dTTgfKrskE5d6OxktxJ4SHeMvmRPka4oAQ97LJmDefn6A@mail.gmail.com>
Date:	Tue, 30 Jun 2015 20:30:05 +0200
From:	Fredrik Markström <fredrik.markstrom@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
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 2:18 PM, Peter Zijlstra <peterz@...radead.org> wrote:
>
> On Tue, Jun 30, 2015 at 01:50:15PM +0200, Fredrik Markström wrote:
>> Excellent,
>
> Please do not top post.

Understood, sorry !

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

You are so right, sorry about that ! I agree the test is needed and it needs to
be done with the lock held.

But I don't think the "wobblies" in the division is, since the division doesn't
affect the sum (prev->stime + prev->rtime) anymore, so that comment should
go, right ?

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

Well I guess it can be a problem on a system where 120 cores are doing nothing
but hammering on rusage... on the other hand I feel a system like that
deserves it.  :)

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

Ok, you might be right. Either or I'm letting go now :)

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