Module Name: src
Committed By: snj
Date: Fri Jan 28 07:16:14 UTC 2011
Modified Files:
src/sys/arch/sparc/sparc [netbsd-5]: cpu.c cpuvar.h genassym.cf intr.c
locore.s pmap.c
Log Message:
Pull up following revision(s) (requested by mrg in ticket #1532):
sys/arch/sparc/sparc/cpu.c: revision 1.215 via patch
sys/arch/sparc/sparc/cpuvar.h: revision 1.78 via patch
sys/arch/sparc/sparc/genassym.cf: revision 1.57 via patch
sys/arch/sparc/sparc/intr.c: revision 1.103-1.105 via patch
sys/arch/sparc/sparc/locore.s: revision 1.247, 1.250 via patch
sys/arch/sparc/sparc/pmap.c: revision 1.329 via patch
- print the cpu_number() when we get a strayintr().
- use _MAXNCPU instead of 4
- convert xpmsg_lock from a simplelock to a kmutex
- don't wait for sparc_noop IPI calls
- remove xmpsg_func's "retval" parameter and usage
- remove the IPI at high IPL message
- rework cpu_attach() a bunch, refactoring calls to getcpuinfo() and setting
of cpi, and split most of the non-boot CPU handling into a new function
- make CPU_INFO_FOREACH() work whether modular or not
- move the MP cpu_info pages earlier
- move a few things in cpu.c around to colsolidate the MP code together
- remove useless if (cpus == NULL) tests -- cpus is an array now
with these changes, and an additional change to crazyintr() to not printf(),
i can get to single user shell on my SS20 again. i can run a few commands
but some of them cause hangs. "ps auxw" works, but "top -b" does not.
convert sparc "intrcnt" counters to evcnt(9) style. XXX some of the names
could be better, but i just copied them from the old intrnames in locore.
i benchmarked this with a simple test of ircii ./configure && make, to see
if the additional load/store & arith would cause any noticeable degradation
as the change also converts 32 bit counters to 64 bits. amusingly, the
only trend i saw in this was that for both portions, i see a consistent
(across at least 8 runs) benefit of about 0.8% improvement. ie, the newer
larger code size / counter size code actually runs faster for some reason..
maybe there's a cacheline effect in the size of the code?
XXX the current implementation depends on a couple of things:
XXX - ev_count member of evcnt{} is first and has offset 0
XXX - that sizeof(struct evcnt) equals 32
XXX if these are not true, locore.s has #error's to catch it
- remove unused ft_want_ast()
- give nmi_sun* ENTRY() points so they show up in symbols properly
- add some disabled code to use this cpu's idlelwp area when hatching
a cpu, but right now it makes this worse not better...
To generate a diff of this commit:
cvs rdiff -u -r1.211.8.2 -r1.211.8.3 src/sys/arch/sparc/sparc/cpu.c
cvs rdiff -u -r1.75.10.2 -r1.75.10.3 src/sys/arch/sparc/sparc/cpuvar.h
cvs rdiff -u -r1.56 -r1.56.4.1 src/sys/arch/sparc/sparc/genassym.cf
cvs rdiff -u -r1.100.20.1 -r1.100.20.2 src/sys/arch/sparc/sparc/intr.c
cvs rdiff -u -r1.244.8.2 -r1.244.8.3 src/sys/arch/sparc/sparc/locore.s
cvs rdiff -u -r1.322.20.3 -r1.322.20.4 src/sys/arch/sparc/sparc/pmap.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
