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.
pgpiCkOd3uH8H.pgp
Description: PGP signature
