* Julian Elischer <[EMAIL PROTECTED]> escriurères
> So the question is: what information can PS show
> for a KSE threaded process?
> I have been thinking of:
> Certainly the first thing to decide it WHAT there is to show..
> threads that are in userspace are not visible to ps, or for that matter
> the kernel, as teh Userland thread scheduler may switch between them
> without notifying the kernel. Only threads blocked in the kernel can show
> any information other than "running" For those in the userland there
> is only the information in the associated kse , and priority
> info from the thread is available.
> so for a process you can show:
> process stuff (e.g. uid, pid, ppid)
Hopefully this won't change.
> kseg stuff (e.g. nice value, number runnable threads)
Nice value and stuff are exported anyway via kproc_info.
Maybe we should look at packing an export_thread in there for exported kse
> kse stuff(e.g. RUNNING @ priority 32 on cpu0)
> kse stuff(e.g. RUNNING @ priority 31 on cpu1)
> runnable threads
> thread runnable priority 33
> thread runnable priority 35
> thread runnable priority 37
> sleeping threads
> thread waiting at Mutex net1 prio 33
> thread sleeping at "biord" prio 31
This all has a simple solution. Export each thread as a process via kinfo_\
proc, and ps(1) will use the existing mtxname interfaces and such..
I don't know how simple this is at a code level.
> kseg stuff (for next kseg)
> anyone have thoughts?
It'd be best to be able to poll the userland schedulers and the KSE stuff via
the ptrace(2) interface, I think, or just export things using kinfo_proc and
pad out the struct with things pertinent to KSE's.
Juli Mallett <[EMAIL PROTECTED]> FreeBSD: The Power To Serve
Perception is prejudice / Don't classify me / Accept me as me / Not what you see
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message