tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

At Mon, 31 Oct 2011 21:10:40 +0000, David Laight <> 
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!

I had ignored SYSCALL_TIMES because it seemed from the manual pages to
be lacking per-process hooks, though I was getting to the place where I
might have noticed that this would be an appropriate framework in which
to add per-process support. :-)

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 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.

> 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 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?

BTW, have you ever built and tested a kernel with appropriate instances
If so, do you have suggestions as to where I could try putting those
macros, especially in a netbsd-5 kernel?

In my estimation it's useless to try to make getrusage() show more
accurate user time without also firmly accounting for ISR times as well.

Relatively speaking I don't mind at all taking a small, equitable, hit
in context switching if as a result I can get relatively accurate user
and system (and ISR) times per process as a result.

                                                Greg A. Woods
                                                Planix, Inc.

<>       +1 250 762-7675

Attachment: pgp4k0mXAX2Wu.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index