From owner-freebsd-smp Sat Mar 30 11:21:10 2002 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id CA67337B405; Sat, 30 Mar 2002 11:21:05 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g2UJKxL80198; Sat, 30 Mar 2002 11:20:59 -0800 (PST) (envelope-from dillon) Date: Sat, 30 Mar 2002 11:20:59 -0800 (PST) From: Matthew Dillon Message-Id: <200203301920.g2UJKxL80198@apollo.backplane.com> To: Jake Burkholder Cc: John Baldwin , freebsd-smp@FreeBSD.ORG Subject: Re: RE: Syscall contention tests return, userret() bugs/issues. References: <200203292305.g2TN5nX75021@apollo.backplane.com> <20020330001929.H40695@locore.ca> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org :I think its worth adding a PCPU_INC, which turns into an incl %fs:PC_FIELD :on i386. alpha, ia64 and sparc64 at least use a resrved regitser for the :pcpu pointer which is declared as a register variable in C, so you can just :do pcpup->pc_field++. To make it consistent you'd have to either disable :interrupts or use atomic ops, because none of these architectures have :add or increment instructions that work directly on memory afaik. I'd :be inclined to just blow it off, but as you point out, this can lead to :serious inconsistencies. How about PCPU_LAZY_INC()? i.e. a name that does not infer any sort of exactness in the operation. :> }; :> :> I'm going to let this thread sit over the weekend to allow other :> people to chime in in regards to moving struct vmmeter into a per-cpu :> area. I think I've made a good case for it based on the cache :> contention between cpu's. If no major problems crop up by monday :> I'll start with the syscall counter and then start moving all the :> 'cnt.*' counter code to use the per-cpu area instead. : :This sounds ok to me. I'll mark you down as in favor of the concept. :Yes, most of userret should be merged into ast(). Signals should trigger :an AST so you only do the sig = cursig() if there's really a signal there. :This has the advantage of streamlining the locking, as well getting the :128 bit arithmetic used for signals out of that path. This may need some :tweaking, but I think most of the support for this is already there. Ditto :for the reschedule check. All that userret really needs to do is account :for profiling, and the PS_PROFIL flag doesn't need sched_lock if you're :just testing it, not setting or clearing. Yes. Judging from Bruce's code and my own read, this will be VERY simple to do. :One problem is clearing the ASTPENDING flag. Currently this still needs :sched_lock in order to not distrub the other bits. It would be better :to move it into a separate flags field in the kse, probably on its own. :I think that the flag should be cleared in the MD code, just after its :read as set and we still have interrupts disabled, just before ast() is :called. : :Jake I wouldn't worry about this too much, it isn't in the critical path. i.e. unless we have a need to handle hundreds of thousand of user signal()s a second, there will be no impact unless we have a bug somewhere else in the code (e.g. if the priority handling code were forcing unnecessary reschedules or something like that). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message