: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