hi, The psinfo structure has two variables pr_pctmem and pr_pctcpu. I am using Solaris 10. I looked up the sys/proc.h where there was a corresponding pctcpu field and in sys/thread.h also a pctcpu field. However no corresponding pctmem field was present in either of these two kernel data structures. How would the pr_pctmem would be then calculated given a pid in dtrace? ( a couple of days ago Brendan showed me how to get the pctcpu using curthread->t_pctcpu, however for memory I guess some other solution has to be worked out). Also, there is a field related to the heap size in proc.h : anyone has any idea how accurate that value is and some good rate to sample that value. Currently I am calculating the heap size myself tracing down allocations and frees: if the value in proc.h is accurate enough then should I use that instead? cheers, pankaj
On 2/17/06, Pankaj Maurya <pankaj at iitk.ac.in> wrote:> hi, > The psinfo structure has two variables pr_pctmem and pr_pctcpu. I am > using Solaris 10. I looked up the sys/proc.h where there was a > corresponding pctcpu field and in sys/thread.h also a pctcpu field. > However no corresponding pctmem field was present in either of these two > kernel data structures. How would the pr_pctmem would be then calculated > given a pid in dtrace?It can''t be done easily; it requires quite a bit of grovelling through HAT datastructures.> ( a couple of days ago Brendan showed me how to > get the pctcpu using curthread->t_pctcpu, however for memory I guess > some other solution has to be worked out). Also, there is a field > related to the heap size in proc.h : anyone has any idea how accurate > that value is and some good rate to sample that value. Currently I am > calculating the heap size myself tracing down allocations and frees: if > the value in proc.h is accurate enough then should I use that instead?http://cvs.opensolaris.org/source/more/on/usr/src/uts/common/fs/proc/prsubr.c?t=full%3apr%5fpctmem which points to: http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/vm/vm_rm.c#rm_pctmemory 165 * Defined as the ratio of a_rss for the process to total physical memory. It''s as accurate as the RSS field is. Which has some problems with shared memory. Cheers, - jonathan
> On 2/17/06, Pankaj Maurya <pankaj at iitk.ac.in> wrote: > > hi, > > The psinfo structure has two variables pr_pctmem and pr_pctcpu. I am > > using Solaris 10. I looked up the sys/proc.h where there was a > > corresponding pctcpu field and in sys/thread.h also a pctcpu field. > > However no corresponding pctmem field was present in either of these two > > kernel data structures. How would the pr_pctmem would be then calculated > > given a pid in dtrace? > > It can''t be done easily; it requires quite a bit of grovelling > through HAT datastructures.More generally, we can''t provide access to any of the /proc stats which require extensive computation while locking locks etc. in the DTrace translators. This is why these members are explicitly not defined. As my comment in /usr/lib/dtrace/procfs.d says: /* * Translate from the kernel''s proc_t structure to a proc(4) psinfo_t struct. * We do not provide support for pr_size, pr_rssize, pr_pctcpu, and pr_pctmem. * We also do not fill in pr_lwp (the lwpsinfo_t for the representative LWP) * because we do not have the ability to select and stop any representative. * Also, for the moment, pr_wstat, pr_time, and pr_ctime are not supported, * but these could be supported by DTrace in the future using subroutines. * Note that any member added to this translator should also be added to the * kthread_t-to-psinfo_t translator, below. */ -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/