Source-Changes archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

CVS commit: [netbsd-5] src/sys/arch/sparc/sparc

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 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/ 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/
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.

Home | Main Index | Thread Index | Old Index