[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-mdb-discuss
Subject:    Re: [mdb-discuss] Why the thread is not switch off  ?
From:       Gavin Maltby <Gavin.Maltby () Sun ! COM>
Date:       2007-09-15 20:00:16
Message-ID: 46EC39D0.2090506 () sun ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On 08/28/07 08:15, liujun wrote:
> Hi all,
> If use ::cpuinfo -v ,In my live environment,  you can find a surprise that the \
> thread which lasts big ticks is not switch off  . I'm sorry the following info is \
> too larger ,but I hope your idea.

> ID ADDR        FLG NRUN BSPL PRI RNRN KRNRN SWITCH THREAD      PROC
> 2 30001054000  1b    5    0  60   no    no [b]t-525557[/b] 2a100371cc0 sched
> > > 
> RUNNING <--+    +-->  PRI THREAD      PROC
> READY                59 300011f2000 nscd
> EXISTS                59 300011f2320 nscd
> ENABLE                 0 30001f166a0 java
> 0 30001f05300 syslogd
> 0 30001044660 mdb

Is this an occasional observation, or is this condition solid?

Note that t_disp_time is updated when we switch *from* a thread,
not when switch to it.  See the code in swtch() and swtch)to(), eg


                         /*
                          * restore mstate of thread that we are switching to
                          */
                         restore_mstate(next);

                         CPU_STATS_ADDQ(cp, sys, pswitch, 1);
                         cp->cpu_last_swtch = t->t_disp_time = lbolt;

't' is the outgoing thread (curtrhead) and 'next' is the thread
we've chosen to follow it.

So we only update t_disp_time when we remove a thread from cpu, not
as we put it on.  It indicates when we were last the dispatched
thread on a cpu, not when last we we're dispatched to that cpu
or actually began to ran on it.

For this reason a thread that has slept for a while would have
a high SWITCH value in ::cpuinfo output if we happen to catch
it on cpu just as it wakes up, and there is nothing bad about that
situation.

I also have a suspicion that if the runnable threads on this cpu
(the 5 threads listed above) had been waiting a long time then
their priorities PRI would have been bumped up during their
wait - and we see 3 of them as zero suggesting that has not happened,
so maybe they've not been waiting that long.  That assumes TS class,
and I'm not clear on how that operates these days.

Cheers

Gavin


["smime.p7s" (application/x-pkcs7-signature)]

_______________________________________________
mdb-discuss mailing list
mdb-discuss@opensolaris.org

[prev in list] [next in list] [prev in thread] [next in thread]