Date: Sat, 26 Mar 2005 06:03:39 +1100 From: Peter Jeremy <PeterJeremy@optushome.com.au> To: Yan Yu <yanyu@CS.UCLA.EDU> Cc: freebsd-hackers@freebsd.org Subject: Re: a Q on measuring system performance. Message-ID: <20050325190339.GD43123@cirb503493.alcatel.com.au> In-Reply-To: <Pine.GSO.4.58.0503242211100.5835@panther.cs.ucla.edu> References: <20050318160528.GQ51688@smp500.sitetronics.com> <20050319080215.GX51688@smp500.sitetronics.com> <20050319.230230.35850068.imp@bsdimp.com> <Pine.GSO.4.58.0503242211100.5835@panther.cs.ucla.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2005-Mar-24 23:21:54 -0800, Yan Yu wrote:
>I am trying to measure the overhead added by these instrumentation code.
>my plan is:
> in my user space program, i have something like the following:
>--------------------------------------------
> gettimeofday(&prev_time, NULL);
> for (i=0; i< 1000; i++)
> {
> fd = fopen("tmp", "r" );
> if (fd == NULL)
> {
> break;
> }
> cnt ++;
> }
>
> gettimeofday(&cur_time, NULL);
> t_lapse= misc_tv_offset( &cur_time, &prev_time );
>
>----------------------------------------------------
That approach is reasonable (but the above code leaks file
descriptors) . You might want to increase 1000 and/or use rdtsc() for
timing depending on your accuracy/resolution requirements.
>I would run this for the unmodified kernel, and instrumented kernel.
>compare the t_lapse, my concern is that t_lapse includes context switch
>time when the user process is taken out of run queue.
So would gprof. And gprof has much higher overheads and a granularity
of 10usec.
--
Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050325190339.GD43123>