Hi Mladen, Mladen Nikitovic wrote: > Hi, > > I think I can follow the disp_nrunnable entry in disp_t quite well now. But I > still have some questions. I did an analysis of the usage of this variable > and found this: > > disp_nrunnable is incremented 3 times in the kernel: > A) in setbackdq > B) in setfrontdq > C) in setkpdq > > it is decremented 2 times: > D) in disp > E) in dispdeq > > case C is special for real-time threads and I don't seem to run them, so > basically it boils down to A, B, D, and E. > > whenever disp_nrunnable is incremented or decremented I pass its current > value (dp->disp_nrunnable) together with ID of the cpu that owns the queue > (dp->disp_cpu->cpu_id) to a statistic module that stores the value in a file. > > When I look at the file I see that the values are reasonable in general, but > there are some anomalities. Sometimes, I see that the code for > incrementing/decrementing the disp_nrunnable has been executed, but the value > of the variable stays unmodified, often it has been modified properly the > next time (or following times) it is manipulated. So, the end result looks > good but if I look at the intermediate steps it looks a bit wierd sometimes. > Right, you may be looking before the update is visible from whichever CPU you are looking.
> I assume the processors in the system (I simulate 8 cpus) has the permission > to manipulate eachothers queues. Is that correct? I see locks being acquired > but I don't see where they are realeased. I guess I just have to believe that > they are hadled properly :) > thread lock / disp_lock logic isn't always very obvious > I noticed that there is a membar_enter call just after cases A and B, so I > might need to wait until that instruction has executed, do you agree? The > problem is that there is no membar_enter just after case C and D, why not? > One reason that's there is to force visibility of disp_nrunnable prior to awakening a idle, halted CPU. You want that CPU to be able to see that there's work available, otherwise it could miss the runnable work and go back to sleep. The barrier could probably be moved into the wakeup routine itself, since CPU halting isn't done everywhere...but we would need to verify that's the only reason the barrier is there. This isn't applicable for case D, and for C, there is an implied barrier as we drop the lock prior to calling the wakeup routine. Thanks, -Eric _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
