508 <http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/os/msacct.c#508>/*509 <http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/os/msacct.c#509> * Given the old percent cpu and a time delta in nanoseconds,510 <http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/os/msacct.c#510> * return the new decayed percent cpu: pct * exp(-tau),511 <http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/os/msacct.c#511> * where 'tau' is the time delta multiplied by a decay factor.512 <http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/os/msacct.c#512> * We have chosen the decay factor (cpu_decay_factor in param.c <http://src.illumos.org/source/s?path=param.c&project=illumos-gate>)513 <http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/os/msacct.c#513> * to make the decay over five seconds be approximately 20%.514 <http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/os/msacct.c#514> *515 <http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/os/msacct.c#515> * 'pct' is a 32-bit scaled integer <= 1516 <http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/os/msacct.c#516> * The binary point is to the right of the high-order bit517 <http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/os/msacct.c#517> * of the 32-bit word.518 <http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/os/msacct.c#518> */
According to the commentary t_pctcpu seems not to be very precise. But even with this param we haven't a mechanism for estimating, say, "cpu usage" of the functions (mean, what part of the cpu usage a function takes), except dtrace that can not be used from the kernel. --Daniil Lunev On Thu, Dec 5, 2013 at 10:40 PM, Rafael Vanoni < [email protected]> wrote: > Look for t_pctcpu, it's essentially what prstat(1m) uses. > > Hth > > Rafael > > > > On Dec 5, 2013, at 11:10, Daniil Lunev <[email protected]> wrote: > > Hello. > Measuring and investigating perfomance in Illumos I have faced the problem > that I can't find a mechanism to get a thread's CPU time in the code. Two > things I've found are not applicable: the dtraces' fields in kthread_t are > filled when the dtrace's vtime is enabled only, another is tk_cpu_time and > tk_cpu_ticks in task_t but this way has a bad resolution and updates on > clockticks only. Have I missed anything? If it's all we have, may be it's a > good idea to add some mechanisms for monitoring thread CPU usage inside the > kernel? For example, I have an idea to add a flag to the kthread structure > which makes the kernel to use the dtrace's switch procedures or something > similar if it's enabled. Does it make any sense? Will it be so bad for the > context switching time? > Thanks, > Daniil Lunev. > *illumos-discuss* | > Archives<https://www.listbox.com/member/archive/182180/=now> > <https://www.listbox.com/member/archive/rss/182180/24965146-fd3f1df4> | > Modify <https://www.listbox.com/member/?&;> Your Subscription > <http://www.listbox.com> > > *illumos-discuss* | > Archives<https://www.listbox.com/member/archive/182180/=now> > <https://www.listbox.com/member/archive/rss/182180/25291745-29942103> | > Modify<https://www.listbox.com/member/?&;>Your Subscription > <http://www.listbox.com> > ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
