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. 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 :) 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? BTW, if there are other theories about this behaviour I would be glad to hear about it. Regards, Mladen This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
