Howdy, I would like to measure the time it takes to context switch between two threads in a process. I read through the sched section of the user guide, and was thinking about using curcpu and the on-cpu and off-cpu probes to measure this. Does this seem like the best way to tackle this problem? Thanks, - Ryan -- UNIX Administrator http://daemons.net/~matty
On Tue, May 09, 2006 at 12:23:45PM -0400, Matty wrote:> > Howdy, > > I would like to measure the time it takes to context switch between two > threads in a process. I read through the sched section of the user guide, > and was thinking about using curcpu and the on-cpu and off-cpu probes to > measure this. Does this seem like the best way to tackle this problem?Define what you mean by "context switch", and I can tell you whether or not on-cpu and off-cpu are the appropriate tools to measure it. Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development
Matty wrote:> > Howdy, > > I would like to measure the time it takes to context switch between two > threads in a process. I read through the sched section of the user > guide, and was thinking about using curcpu and the on-cpu and off-cpu > probes to measure this. Does this seem like the best way to tackle this > problem? > > Thanks,The problems you''re going to have are that dtrace''s probe effect is non-zero when measuring events at small numbers of microseconds, and that dtrace''s attempts to remove it''s own probe effects aren''t super accurate. DTrace timing works well enough for determining deltas w/ code changes but if you''re looking to compare numbers w/ other operating systems I suggest using a microbenchmark instead. Libmicro''s pipe benchmark does this pretty well. Note that you''ll get very different results depending on how the threads end up running on your cpus. Performance will be much better if both threads run on the same cpu. -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts
> >I would like to measure the time it takes to context switch between two > >threads in a process. I read through the sched section of the user > >guide, and was thinking about using curcpu and the on-cpu and off-cpu > >probes to measure this. Does this seem like the best way to tackle this > >problem? > > > >Thanks, > > The problems you''re going to have are that dtrace''s probe effect > is non-zero when measuring events at small numbers of microseconds, > and that dtrace''s attempts to remove it''s own probe effects aren''t > super accurate.Indeed, it is virtually impossible for even a single additional instruction to account for the effect of its execution: there is no way to account for pollution of implicit state like the cache, the pipeline, the branch target buffer, etc. This is particularly exacerbated when looking at code paths like context switching, which tries to minimize this kind of pollution. So as Bart says, exercise great caution when treating DTrace numbers in any kind of absolute sense -- especially as those numbers become small (hundreds of microseconds or less)... - Bryan -------------------------------------------------------------------------- Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc
On Tue, 9 May 2006, Jonathan Adams wrote:> Define what you mean by "context switch", and I can tell you whether or not > on-cpu and off-cpu are the appropriate tools to measure it.Hi Jonathon, I am using "context switch" in the context of mpstat''s ''csw'' and ''icsw'' columns. To provide some background, I have doing a comparison of Solaris 10 x86 running on raw hardware (Sun V20Zs) with Solaris 10 x86 running in a virtual machine. To understnad the overhead associated with the virtualized environment, I have been running sysbench in each environment: http://sysbench.sourceforge.net/docs/#threads_mode The ''threads'' test provided some interesting values, so I wanted to dig in deeper to see where the slowdown was occurring. I thought a good place to start would be to gather the min, max and average CPU times required to switch between threads, and to perform the mutex_lock() and mutex_unlock() operations. Since the sched provider has the on-cpu and off-cpu probes, I thought these would be ideal for measuring the time it took to switch between threads (especially since psinfo_t and cursinfo_t contain lots of useful info). Do you think this is the right way to measure this? If not, any suggestions? Thanks for the feedback, - Ryan -- UNIX Administrator http://daemons.net/~matty
Hi,
There must be an obvious answer to why this:
dtrace -n thread_create:entry''/args[2] ==
genunix`mt_config_thread/{stack();}''
results in this:
dtrace: error on enabled probe ID 1 (ID 16449: fbt:genunix:thread_create:entry):
invalid alignment (0xfffffffffb9af9ae) in predicate at DIF offset 12
But I''m not seeing it -- mdb verifies that that''s the right
address for
mt_config_thread:
# mdb -k
...> genunix`mt_config_thread=J
fffffffffb9af9ae
I''m running 5/5 nightlies...
--S
Seth Goldberg
2006-May-09 21:05 UTC
[dtrace-discuss] Invalid alignment in predicate (followup)
Woops -- just found this in the archives -- sorry for the noise.
It''s bug:
6400262 DTrace requires more alignment than necessary
--S
Quoting Seth Goldberg, who wrote the following on Tue, 9 May 2006:
> Hi,
>
> There must be an obvious answer to why this:
>
> dtrace -n thread_create:entry''/args[2] ==
> genunix`mt_config_thread/{stack();}''
>
> results in this:
>
> dtrace: error on enabled probe ID 1 (ID 16449:
> fbt:genunix:thread_create:entry): invalid alignment (0xfffffffffb9af9ae) in
> predicate at DIF offset 12
>
> But I''m not seeing it -- mdb verifies that that''s the
right address for
> mt_config_thread:
>
> # mdb -k
> ...
>> genunix`mt_config_thread=J
> fffffffffb9af9ae
>
>
> I''m running 5/5 nightlies...
>
> --S
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
>
On Tue, May 09, 2006 at 02:02:18PM -0700, Seth Goldberg wrote:> Hi, > > There must be an obvious answer to why this: > > dtrace -n thread_create:entry''/args[2] == > genunix`mt_config_thread/{stack();}'' > > results in this: > > dtrace: error on enabled probe ID 1 (ID 16449: > fbt:genunix:thread_create:entry): invalid alignment (0xfffffffffb9af9ae) in > predicate at DIF offset 12 > > But I''m not seeing it -- mdb verifies that that''s the right address for > mt_config_thread: > > # mdb -k > ... > >genunix`mt_config_thread=J > fffffffffb9af9aeHrm; it looks like it''s trying to dereference the function. You want to do: dtrace -n ''thread_create:entry/arg2 == (uintptr_t)&genunix`mt_config_thread/ {stack();}'' as a work-around. Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development
Hi, Quoting Jonathan Adams, who wrote the following on Tue, 9 May 2006:> > Hrm; it looks like it''s trying to dereference the function. You want to > do: > > dtrace -n ''thread_create:entry/arg2 == (uintptr_t)&genunix`mt_config_thread/ > {stack();}'' > > as a work-around.Sorry, unfortunately, that still doesn''t work. # dtrace -n thread_create:entry''/arg2 == (uint64_t)genunix`mt_config_thread/{stack();}'' dtrace: description ''thread_create:entry'' matched 1 probe dtrace: error on enabled probe ID 1 (ID 16449: fbt:genunix:thread_create:entry): invalid alignment (0xfffffffffb9af9ae) in predicate at DIF offset 8 --S
On Tue, May 09, 2006 at 02:11:12PM -0700, Seth Goldberg wrote:> Hi, > > > Quoting Jonathan Adams, who wrote the following on Tue, 9 May 2006: > > > > >Hrm; it looks like it''s trying to dereference the function. You want to > >do: > > > >dtrace -n ''thread_create:entry/arg2 == > >(uintptr_t)&genunix`mt_config_thread/ > > {stack();}'' > > > >as a work-around. > > Sorry, unfortunately, that still doesn''t work. > > # dtrace -n thread_create:entry''/arg2 == > (uint64_t)genunix`mt_config_thread/{stack();}''^^^ Cast to (uintptr_t), and put a & before genunix. Then, it will work. Cheers, - jonathan> dtrace: description ''thread_create:entry'' matched 1 probe > dtrace: error on enabled probe ID 1 (ID 16449: > fbt:genunix:thread_create:entry): invalid alignment (0xfffffffffb9af9ae) in > predicate at DIF offset 8 > > --S-- Jonathan Adams, Solaris Kernel Development
Quoting Jonathan Adams, who wrote the following on Tue, 9 May 2006:> On Tue, May 09, 2006 at 02:11:12PM -0700, Seth Goldberg wrote: >> Hi, >> >> >> Quoting Jonathan Adams, who wrote the following on Tue, 9 May 2006: >> >>> >>> Hrm; it looks like it''s trying to dereference the function. You want to >>> do: >>> >>> dtrace -n ''thread_create:entry/arg2 =>>> (uintptr_t)&genunix`mt_config_thread/ >>> {stack();}'' >>> >>> as a work-around. >> >> Sorry, unfortunately, that still doesn''t work. >> >> # dtrace -n thread_create:entry''/arg2 =>> (uint64_t)genunix`mt_config_thread/{stack();}'' > ^^^ > Cast to (uintptr_t), and put a & before genunix. Then, it will work.Sorry about that -- too little sleep :(. --S
On Tue, May 09, 2006 at 02:02:18PM -0700, Seth Goldberg wrote:> Hi, > > There must be an obvious answer to why this: > > dtrace -n thread_create:entry''/args[2] == > genunix`mt_config_thread/{stack();}''It''s treating that as a pointer, and comparing args[2] to the first instruction of mt_config_thread(). You need to take the address of mt_config_thread() instead: /args[2] == &genunix`mt_config_thread/ You''ll probably also need to throw in some casting (to "void *" would be easiest) to get the compiler to swallow it.... - Bryan -------------------------------------------------------------------------- Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc
On Tue, May 09, 2006 at 02:06:42PM -0700, Jonathan Adams wrote:> Hrm; it looks like it''s trying to dereference the function.... and that''s reporting an alignment problem because of this: 6400262 DTrace requires more alignment than necessary Adam -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl