Julian Elischer wrote: > Kris Kennaway wrote: > >> >> Correct me if I'm wrong, but the stats aren't accounted to the parent >> process either. I'm pretty sure I've seen situations where a thread >> was using a lot of CPU, but if you believe top(1) then every process >> in the system is idle (except for the fact that the system is 0% >> idle). In this situation there's no way to tell which threaded >> process is using resources. >> >> > > you may be right.. I plan to examine stats over the next week as part of > the kernel threads work. > I may be able to improve the situation. > Um, would this be considered a security flaw, since process time limits likely aren't being enforced? > my aim is that for threads that are doing M:N work the stats will > accumulate on the thread > for a short while and then be collected to the KSEG when ther eis reason > to think that > the kernel thread has changed purpose or exits (both of which happen a > lot in KSE). > > for 1:1 threads, they will continue to accumulate on the thread, since > no "KSE events" will > occur. > > The KSEGRPs stats will be collected to the process when asked for. > I will probably also change the way that 'ps' shows these (and threads). > I'm not sure what to do about top yet. we really need to be able to show a > process name AND a thread name when the threads are shown and have names. > >> Kris >> Does pthreads allow the programmer to name threads in a user and/or kernel visible way? Is this something that is really all that important? ScottReceived on Fri Jan 20 2006 - 18:23:54 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:51 UTC