Hi: ftb:unix::entry getting processor binding status via processor_bind and cpu_bind per zone,project and task, process via specific probe action handling. It depends on api call back to probe action. Is there any non-api dirven binding status or kernel structure counter value accessable ? Thanks This message posted from opensolaris.org
Hi On 11/09/05 07:35, ttoulliu2002 wrote:> Hi: > > ftb:unix::entry getting processor binding status > via processor_bind and cpu_bind per zone,project > and task, process via specific probe action handling. > It depends on api call back to probe action. > > Is there any non-api dirven binding status or kernel > structure counter value accessable ?In the kthread_t you''ll find struct cpu *t_bound_cpu; /* cpu bound to, or NULL if not bound */ short t_bind_cpu; /* user-specified CPU binding (-1 if none) */ short t_affinitycnt; /* nesting level of kernel affinity-setting */ which I think is what you''re looking for. If a thread is bound to a cpu from a kernel request - eg via thread_affinity_set - then t_bound_cpu will point to the cpu it is bound to and t_bind_cpu will be -1. If it is bound from a userland request (pbind(1m) command, processor_bind(2) syscall) then t_bound_cpu will again point to the cpu but this time the user-specified cpuid for binding also appears in t_bind_cpu. t_affinitycnt counts the number of nested affinity_set calls. Also related (depending on the question you seek to answer) are struct cpupart *t_cpupart; /* partition containing thread */ int t_bind_pset; /* processor set binding */ for processor set binding volatile char t_preempt; /* don''t preempt thread if set */ for kpreempt_disable() which also amounts to binding provided the thread does not block, and struct cpu *t_weakbound_cpu; /* cpu weakly bound to */ char t_nomigrate; /* do not migrate if set */ for the very short-term binding offered by thread_nomigrate(). If you want to see the beginnings of the delicate ballet played out by all these binding controls start with setfrontdq() and setbackdq() which decide where a thread can be queued to run. Cheers Gavin
On Tue, Nov 08, 2005 at 11:35:34PM -0800, ttoulliu2002 wrote:> Hi: > > ftb:unix::entry getting processor binding status > via processor_bind and cpu_bind per zone,project > and task, process via specific probe action handling. > It depends on api call back to probe action.curpsinfo->pr_bindpro and curpsinfo->pr_bindpset will tell you the current settings for a given process, and in a stable fashion. Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development
Jonthan: Thanks for your reply. I tends to address system, zone, project, task and process scoped standard SRM. As you mentioned, curpsinfo is tighted to process specific bindings. In addition, walk through from process level up to system does not look efficient for me. Did I miss your point ? Thanks This message posted from opensolaris.org
Gavin: Thanks for your reply. kernelthread_t is visiable from ftb:unix:<specific processor binding call>:entry as args[0] which works as I mentioned in the earlier message. However, it is coupled with specific API call back required. I need API agnostic kernel structure or counter variable for the access such as curpsinfo addressed at process level. Thanks This message posted from opensolaris.org
On Wed, Nov 09, 2005 at 12:45:31PM -0800, ttoulliu2002 wrote:> Gavin: > > Thanks for your reply. kernelthread_t is visiable > from ftb:unix:<specific processor binding call>:entry > as args[0] which works as I mentioned in the earlier > message. However, it is coupled with specific API > call back required. I need API agnostic kernel structure > or counter variable for the access such as curpsinfo > addressed at process level.I don''t understand exactly what you are trying to do; even if there were a such a structure, dtrace(1M) does not seem to be the right tool to walk it. You can get most this information by just reading /proc/*/psinfo, /proc/*/lwp/*/lwpsinfo and correlating: taskid_t pr_taskid; /* task id */ projid_t pr_projid; /* project id */ zoneid_t pr_zoneid; /* zone id */ with processorid_t pr_bindpro; /* processor to which lwp is bound */ psetid_t pr_bindpset; /* processor set to which lwp is bound */ Processes and threads are bound to cpus and processor sets; the larger task and project groupings do not have to have all processes in them bound identically. Even more easily, you could just use "pbind -Q" and "psrset -Q" to see all processes bound to cpus and processor sets, respectively. Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development
Johathan: Thanks for your reply. curthread limits to current kernel thread which has the similar limitation as curpsinof to current process. It seems the aggreation has to be done at externally then. Thanks This message posted from opensolaris.org
Hi On 11/09/05 20:45, ttoulliu2002 wrote:> Gavin: > > Thanks for your reply. kernelthread_t is visiable > from ftb:unix:<specific processor binding call>:entry > as args[0] which works as I mentioned in the earlier > message. However, it is coupled with specific API > call back required. I need API agnostic kernel structure > or counter variable for the access such as curpsinfo > addressed at process level.What is the end result you wish to achieve, ie what problem or question are you aiming to address? It''s no a "stable" structure, but kthread_t is where all info for any given threadid resides - all you need is thre threadid (ktrhead_t address). So you''re not tied to the bind entry points - if you have a thread id t in your hand, from whatever method, you can use t->t_bind_cpu etc to look at its info (remembering, of course, that if it not curthread then the thread may have exited already). Hope that helps Cheers Gavin
Gavin: Thanks for your reply. kthread_t is good for me understand the resource under current kernel thread context. However, it is not sufficient for me to understand the resource under high level at task, prject and zone even up to system level. Where is the handle for aggregation then with SRM model on solaris platform Thanks This message posted from opensolaris.org