Re: getrusage() problems with user vs. system time reporting

[David Laight <david%l8s.co.uk@localhost>]

On Mon, Oct 31, 2011 at 04:08:13PM -0700, Greg A. Woods wrote:
> At Mon, 31 Oct 2011 21:10:40 +0000, David Laight <david%l8s.co.uk@localhost> 
> wrote:
> Subject: Re: getrusage() problems with user vs. system time reporting
> > 
> > There is an kernel option in i386 (and maybe amd64) to do some
> > per-syscall stats. One of those counts 'time in syscall' and IIRC
> > could easily be used to weight the tick counts so that getrusage
> > gives more accurate times.
> 
> I had no idea there was a SYSCALL_TIMES_PROCTIMES option as well!  (and
> I see it's been sitting there un-documented since 2007, and so it is
> already in the netbsd-5 sources I'm experimenting with!)  This is
> exciting!  This is what I was looking for!

All of those options were some experiments/investigations I was
doing trying to see which part of the netbsd build took all the time.
From memory failing open() system calls dominate!
 
> So, if I understand the way SYSCALL_TIMES_PROCTIMES is implemented it
> effectively converts the struct proc p_*ticks fields into cycle counts
> instead of stathz tick counts.  (though it seems enabling this does not
> disable the additional accumulation of stathz ticks, nor does it adjust
> the calculations in kern_resource.c to give expected values)

It doesn't matter. With the cycle counter values, the stathz ticks
are noise. The counts are then a bit like doing the stathz count
on every tick of the cycle counter!

> It looks like SYSCALL_TIMES is indeed on both i386 and amd64 at this
> time, which will do fine for me for now, but given how it seems to work
> it looks like it could be made to work on alpha, mips, powerpc, sparc64,
> and ia64 with relative ease.

Indeed.

> > The problem is that getting an accurate timestamp is relatively
> > expensive. It has been almost the dominant part of process switch.
> 
> Because they do use cpu_counter32(), I'm surprised they would be that
> expensive to keep.

If a cpu's TSC rate changes (eg with power saving) they they'll give
different results. So you'd really need a nanotime function.
OTOH using the valuse to split the total execution time is probably
always better than the current code.

Getting the TSC is (IIRC) 30-40 clocks on i386 - because it is a
synchronising instruction. But it might be the delays only really
affect back to back reads. ad@ knows more - it will be in the
archives somewhere.

> If one were to get rid of the big syscall_counts and syscall_times
> tables and just use the bits necessary for SYSCALL_TIMES_PROCTIMES,
> would that help reduce the overhead to a more acceptable level?

The options could probably be separated a little better.
But, as I said, they were really experimental.
 
> BTW, have you ever built and tested a kernel with appropriate instances
> of SYSCALL_TIME_ISR_ENTRY() and SYSCALL_TIME_ISR_EXIT() put into place?
> If so, do you have suggestions as to where I could try putting those
> macros, especially in a netbsd-5 kernel?

I really can't remember!

        David

-- 
David Laight: david%l8s.co.uk@localhost