Date: Sat, 30 Mar 2002 11:20:59 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Jake Burkholder <jake@locore.ca> Cc: John Baldwin <jhb@FreeBSD.ORG>, freebsd-smp@FreeBSD.ORG Subject: Re: RE: Syscall contention tests return, userret() bugs/issues. Message-ID: <200203301920.g2UJKxL80198@apollo.backplane.com> References: <XFMail.20020329171752.jhb@FreeBSD.org> <200203292305.g2TN5nX75021@apollo.backplane.com> <20020330001929.H40695@locore.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203301920.g2UJKxL80198>