On Tue, Jun 30, 2015 at 2:18 PM, Peter Zijlstra <pet...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
