Re: [PATCH RFC] time: drop do_sys_times spinlock

[Peter Zijlstra <peterz@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1584 bytes --]

On Wed, Aug 13, 2014 at 09:24:06AM -0400, Rik van Riel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 08/13/2014 07:11 AM, Peter Zijlstra wrote:
> > On Wed, Aug 13, 2014 at 08:59:50AM +0200, Mike Galbraith wrote:
> > 
> >> I was told that clock_gettime(CLOCK_PROCESS_CPUTIME_ID) has
> >> scalability issues on BIG boxen
> > 
> >> I'm sure the real clock_gettime() using proggy that gummed up a
> >> ~1200 core box for "a while" wasn't the testcase below, which
> >> will gum it up for a long while, but looks to me like using
> >> CLOCK_PROCESS_CPUTIME_ID from LOTS of threads is a "Don't do
> >> that, it'll hurt a LOT".
> > 
> > Yes, don't do that. Its unavoidably slow and bad.
> 
> I don't see why that needs the tasklist_lock, when do_sys_times
> grabs a different lock.
> 
> If the same bottleneck exists from multiple places, maybe it does
> make sense to have a seqlock for the statistics at the sighand
> level?
> 
> I can code up a patch that does that, and throw it over the wall
> to people with big systems who hit that bottleneck on a regular
> basis...

PROCESS_CPUTIME doesn't need tasklist lock; it only takes the sighand
lock. It needs that to stabilize the thread list, you cannot give a
straight answer if threads are coming/going.

It further needs to take the rq->lock for any active task in the thread
group.

Combined its painful; and it being painful should be no surprise to
anybody seeing how its basically a 'global' property -- the more CPUs
you stick in a machine the more expensive those become.

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]