[Python-checkins] r46505 -python/trunk/Tools/pybench/systimes.py

[Fredrik Lundh]

Tim Peters wrote:

> My understanding is that the docs are correct there, and "kernel mode"
> could just as well (perhaps better) be called "privileged mode".  The
> OS kernel runs at a higher privilege level, which is partly enforced
> by modern CPU hardware.  For example, code triggered by HW interrupts
> runs in privileged mode, and can execute instructions that the HW
> refuses to execute in "user mode", and access the entirety of physical
> RAM directly.  Device drivers usually run in privileged/kernel mode
> too.  This isn't the same as "Win32 API call", neither is it the same
> as anything else that can make instant sense to a non-OS hacker.

well, yes and no -- the time needed to handle HW interrupts, kernel 
processes, etc will of course be assigned to those processes, not your 
user process.  when the scheduler interrupts your process to "handle a 
tick", it knows very well what process it was interrupting, and whether 
that process was running in privileged mode or not.

(and for an ordinary user process running in the win32 subsystem, the 
best way to end up in kernel space is to call a win32 api function that 
(directly or indirectly) requires kernel-level support).

> In any case, distinguishing between user time and system time is
> pretty much pointless in most benchmarks.  I want to know how long the
> code takes, and couldn't care less how much of it runs with some CPU
> privilege bit set (unless, as mentioned before, I'm running on a
> timesharing mainframe and get charged different rates for user time
> than for system time).

if you're running on a mainframe, chances are that you have excellent 
hardware support for this ;-)

> BTW, it may be the case that time waiting for a page fault to get
> resolved from disk doesn't get charged against "user time" or "kernel
> time" (depends on OS details).

oh, I find it hard to believe that any modern operating system would 
consider waiting for I/O to finish to be a user process issue...

> But if a code change is made that
> significantly increases or decreases page faults, that's certainly
> something a benchmarker wants to know about.  A high-resolution
> wall-clock timer is typically the only way to approach measuring that
> kind of thing directly.

absolutely.

but I don't think we have that kind of tests in PyBench; they are all 
interpreter microbenchmarks, and virtually the only thing that can cause 
them to end up in kernel space on their own is memory allocations...

</F>