Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Apr 2001 18:33:17 -0700 (PDT)
From:      Matthew Jacob <mjacob@feral.com>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org
Subject:   RE: cvs commit: src/sys/alpha/alpha mp_machdep.c
Message-ID:  <Pine.BSF.4.21.0104251832590.6780-100000@beppo.feral.com>
In-Reply-To: <XFMail.010425181100.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

My opinion is that I'd rather have the smp patch in than out. FWIW, which
ain't much.


On Wed, 25 Apr 2001, John Baldwin wrote:

> 
> On 25-Apr-01 John Baldwin wrote:
> > 
> > On 25-Apr-01 John Baldwin wrote:
> >> 
> >> On 25-Apr-01 John Baldwin wrote:
> >>> jhb         2001/04/25 10:24:57 PDT
> >>> 
> >>>   Modified files:
> >>>     sys/alpha/alpha      mp_machdep.c 
> >>>   Log:
> >>>   - Make the dumping of console messages from the secondary CPU's to the
> >>>     kernel console be #ifdef DIAGNOSTIC.
> >>>   - Don't set ktr_mask in release_aps().
> >> 
> >> Unfortunately, top of the tree still panic's (kind of cute when two cpu's
> >> panic
> >> at the exact same time and clobber each other's panic messages.).  I'm
> >> working
> >> on smp.patch next which doesn't panic but changes many things.  I'm still
> >> trying to figure out why each CPU is doling out 115% of p_cpticks for each
> >> schedcpu() update.
> > 
> > Well, it turns out that on the dual 300 21164, the overhead of witness and
> > invariants (probably mostly witness) delays schedcpu() enough that p_cpticks
> > can end up as high as 146 for a second even though stathz is 128.  Turning
> > off
> > witness made this go away.  :(  Anyways, I'll be posting my smp.patch which
> > is
> > known to work on both UP and SMP alpha and x86.  In fact, for the alpha we
> > can
> > even run an SMP kernel on UP machines, so for 5.0 we should be able to enable
> > SMP in GENERIC if that is desired.  I'll post a URL and description of the
> > patch to -smp shortly.
> 
> Well, apparently I was looking at the wrong xterm or smoking crack, because I'm
> still getting somewhat bogus p_pctcpu's even without witness:
> 
>    10 root     -16    0     0K     0K RUN    1   4:20 115.04% 115.04% idle: cpu
>    11 root     -16    0     0K     0K CPU0   0   4:21 114.84% 114.84% idle: cpu
>   437 jhb       20    0  2056K  1912K pause  0   0:00  2.23%  0.88% tcsh
>   436 root       4    0  4568K  3112K select 0   0:00  0.62%  0.24% sshd
>    13 root     -48 -167     0K     0K *Giant 0   0:02  0.00%  0.00% swi6: tty:s
>   407 jhb        4    0  3040K  2088K select 1   0:01  0.00%  0.00% top
> 
> Notably, the idle processes are rather bogus.  The problem is that we are
> ending up with p_cpticks up around 145 or 146 when schedcpu() is run, even
> though stathz is 128 on the alpha.  Not sure why this is broken, but having
> somewhat off p_pctcpu but an otherwise stable system is much better than
> panic'ing at boot, so I'd like to commit smp.patch even with this known bug.
> 
> -- 
> 
> John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
> PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
> "Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0104251832590.6780-100000>