Messages in this thread | | | From | Fredrik Markström <> | Date | Tue, 30 Jun 2015 20:30:05 +0200 | 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@infradead.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
| |