From owner-freebsd-current Wed Jun 10 08:49:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA29517 for freebsd-current-outgoing; Wed, 10 Jun 1998 08:49:17 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA29469 for ; Wed, 10 Jun 1998 08:49:04 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id BAA29945; Thu, 11 Jun 1998 01:49:01 +1000 Date: Thu, 11 Jun 1998 01:49:01 +1000 From: Bruce Evans Message-Id: <199806101549.BAA29945@godzilla.zeta.org.au> To: bde@zeta.org.au, phk@critter.freebsd.dk Subject: Re: Spurious SIGXCPU Cc: current@FreeBSD.ORG, jb@cimlogic.com.au, jdp@polstra.com, rb@gid.co.uk Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>Another sign of the bug is that accounting for rapid context switches >>is broken again: >> >> $ time ./fork-benchmark 10000 >> 6.10 real 0.01 user 8.33 sys > >if you make it always call > microuptime(&p->p_switchtime); > >after cpu_switch() in kern_synch, does that make it any different ? Probably. I fixed it by clearing switchtime.tv_sec in fork_trampoline() and am now trying to figure out why that works :-). `switchtime' lags the current time by about 10 usec when fork_trampoline() is reached, so about 10 usec per fork is lost by forgetting it. This doesn't explain why about 200 usec per fork is gained by not forgetting it or why the rlimit expires. The proc fields seem to be cleared properly (except it is a waste of time to clear p_switchtime - if 0 were ever used, then the runtime would be about 28 years. RLIM_INFINITY microseconds expires after only about 292271 years :-). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message