thread kernel time
roy gordon
old-time systems programmer), so please forgive any obvious questions,
lack of common knowledge, etc.)
I want to determine the time taken in some of our system components
wrt a given thread.
It looks to me that I can get this information directly from the
KernelTime member of the ETHREAD structure.
But, if so, when is KernelTime incremented?
(1) Is it on the clock cycle
or
(2) something like the following sequence starting from (a), then the
others:
(a) system entry
(b) when switched out
(c) when switched in
(d) when leaving kernel
(3) ????
Is there an internal API I can use to get this info?
Thanks.
-- Roy
Neill Clift [MS]
change from release to release. You will in fact find that
it has if you check between say Win2k and XP.
We need to be able to change system data structures like
this to add new features, improve performance or reclaim
unused space.
I don't believe there is documented interface to get at
this information from kernel mode (say from a driver). We
do have interfaces from user mode that get this
information (GetThreadTimes for example).
This field is maintained by a periodic timer interrupt
that looks at the previous mode of the thread and
increments the appropriate counter.
Neill.
>.
>
Roy Gordon
> >[ want to get KernelTime when in kernel ]
We want to benchmark our individual functions within the kernel, some of
which run in the context of a switchable thread and others in arbitrary
thread context in a driver (not switchable).
So, accessing the KernelTime in user mode does us no good. And, because we
could be switched out in the one case, neither does using Intel's RDTSC
instruction.
I realize that KernelTime in itself is not exact since the thread in
question can be charged during any arbitrary interrupt and also will often
not be charged if it is switched out before the clock interrupt occurs.
But, we need to do the best we can.
Is there some other way to accomplish this? One that is also carries the
imprimatur?
It seems pretty weird to me that there isn't a documented kernel interface
to provide this information, particularly if it were read only. I don't
want to access ETHREAD directly, although in this case since it's for
benchmarking only and not production we could deal with the structure
changing. Right now we're only concerned with win2k.
-- Roy
"Neill Clift [MS]" <nei...@microsoft.com> wrote in news:5dd201c19589
$6c6aeed0$9ee62ecf@tkmsftngxa05:
Andre Vachon [MS]
Then you can measure what you actually care about.
-Andre
"Roy Gordon" <ro...@semantic.com> wrote in message
news:Xns918CF229DA4B...@208.201.224.154...
Roy Gordon
news:#r$G7LhlBHA.1540@tkmsftngp05:
> Why don't you just add some timer code in or around your routines ?
> Then you can measure what you actually care about.
>
> -Andre
The thread is switchable, so how could we do this? I mean, we don't want
to include the time when we're switched out.
In the code which isn't switchable this is what I will probably wind up
doing: simply using the RDSTC instruction. I'd prefer though a reasonable
general mechanism that I can use for both.
I'm now thinking that since this is only for benchmarking I will provide
for raising the irql for each section of code we want to profile allowing
for dynamic selection via a driver ioctl.
But, there's got to be a better way.
Here's my question to you microsoft os gurus: why isn't the TSC register
used to track thread kernel and user time instead of the gross clock
interrupt interval? This would seem simple to do. Is it considered too
inefficient? It would only have to be done when the thread enters/leaves
system mode and when the thread is switched out/in. The quantum could still
be tied to the clock interrupt.
In looking at the Intel IA architecture manual it looks like the TSC was
available with the early Pentium processors.
From the "RDTSCç”±ead Time-Stamp Counter" reference in The IA-32 Intel
Architecture Software Developerç—´ Manual V.2 p 3-675:
This instruction was introduced into the IA-32
Architecture in the Pentium processor.
If the TSC weren't present, dynamically determined, the current method
could be used.
-- Roy
Schorschi Decker
to split out the kernel cycles from user mode. I looked at the API sequence
with TaskManager running, but just don't know ASM well enough on Intel to
see the context switch or where to hook the switch. Still looking.
"Roy Gordon" <ro...@semantic.com> wrote in message
news:Xns918D86524BE5...@208.201.224.154...
> "Andre Vachon [MS]" <andrev...@microsoft.com> wrote in
> news:#r$G7LhlBHA.1540@tkmsftngp05:
>
> > Why don't you just add some timer code in or around your routines ?
> > Then you can measure what you actually care about.
> >
> > -Andre
>
> The thread is switchable, so how could we do this? I mean, we don't want
> to include the time when we're switched out.
>
> In the code which isn't switchable this is what I will probably wind up
> doing: simply using the RDSTC instruction. I'd prefer though a reasonable
> general mechanism that I can use for both.
>
> I'm now thinking that since this is only for benchmarking I will provide
> for raising the irql for each section of code we want to profile allowing
> for dynamic selection via a driver ioctl.
>
> But, there's got to be a better way.
>
> Here's my question to you microsoft os gurus: why isn't the TSC register
> used to track thread kernel and user time instead of the gross clock
> interrupt interval? This would seem simple to do. Is it considered too
> inefficient? It would only have to be done when the thread enters/leaves
> system mode and when the thread is switched out/in. The quantum could
still
> be tied to the clock interrupt.
>
> In looking at the Intel IA architecture manual it looks like the TSC was
> available with the early Pentium processors.
>
> From the "RDTSC-Read Time-Stamp Counter" reference in The IA-32 Intel
> Architecture Software Developer's Manual V.2 p 3-675:
Nico Bendlin
Nt/ZwQuerySystemInformation with
SystemProcessAndThreadsInformation ( named by Nebbett )
This function / structures are not officially documented...
...you should not use it in production code.
( user mode: ntdll.dll; kernel mode: ntoskrnl.exe )
The offset of thread info is different between NT4 and 2K/XP !
For more information see
Gary Nebbett
Windows NT/2000 Native API Reference
http://www.newriders.com/native/
( source is provided on the site )
Regards,
Nico
"Schorschi Decker" <Scho...@DSLExtreme.COM> schrieb im Newsbeitrag
news:u3eunh...@corp.supernews.com...
Andre Vachon [MS]
and DPCs which can interupt code at passive level pretty much anytime.
-Andre
"Roy Gordon" <ro...@semantic.com> wrote in message
news:Xns918D86524BE5...@208.201.224.154...
> "Andre Vachon [MS]" <andrev...@microsoft.com> wrote in
> news:#r$G7LhlBHA.1540@tkmsftngp05:
>
> > Why don't you just add some timer code in or around your routines ?
> > Then you can measure what you actually care about.
> >
> > -Andre
>
> The thread is switchable, so how could we do this? I mean, we don't want
> to include the time when we're switched out.
>
> In the code which isn't switchable this is what I will probably wind up
> doing: simply using the RDSTC instruction. I'd prefer though a reasonable
> general mechanism that I can use for both.
>
> I'm now thinking that since this is only for benchmarking I will provide
> for raising the irql for each section of code we want to profile allowing
> for dynamic selection via a driver ioctl.
>
> But, there's got to be a better way.
>
> Here's my question to you microsoft os gurus: why isn't the TSC register
> used to track thread kernel and user time instead of the gross clock
> interrupt interval? This would seem simple to do. Is it considered too
> inefficient? It would only have to be done when the thread enters/leaves
> system mode and when the thread is switched out/in. The quantum could
still
> be tied to the clock interrupt.
>
> In looking at the Intel IA architecture manual it looks like the TSC was
> available with the early Pentium processors.
>
> From the "RDTSC-Read Time-Stamp Counter" reference in The IA-32 Intel
> Architecture Software Developer's Manual V.2 p 3-675:
Slava M. Usov
> "Andre Vachon [MS]" <andrev...@microsoft.com> wrote in
> news:#r$G7LhlBHA.1540@tkmsftngp05:
>
> > Why don't you just add some timer code in or around your routines ?
> > Then you can measure what you actually care about.
> >
> > -Andre
>
> The thread is switchable, so how could we do this? I mean, we don't want
> to include the time when we're switched out.
Simple: you pretend it's not being switched :-) Seriously, you have two
different approaches: if the section of code you want to profile is short,
use RDTSC and KeQueryTickCount() -- the latter will let you detect timer
interrupt intervention and discard the measurement. For long sections of
code, the existing OS support for thread kernel time should be more or less
adequate. For a portable way to get thread times in kernel-mode, see ntddk.h
and the KERNEL_USER_TIMES structure, and the THREADINFOCLASS enum, and its
ThreadTimes particularly; then, in the same file, find the declaration of
NtQueryInformationProcess(), copy it, paste into a file of yours, replace
"Process" with "Thread", and PROCESSINFOCLASS with THREADINFOCLASS; use
NtCurrentThread() to get the current thread handle for that routine.
[...]
> I'm now thinking that since this is only for benchmarking I will provide
> for raising the irql for each section of code we want to profile allowing
> for dynamic selection via a driver ioctl.
If you only want to prevent the thread from being preempted, you might make
its priority realtime. It should work far better than raising its IRQL to
the dispatch level, since you won't be able to use much of OS services at
the elevated IRQL.
S