Re: [PATCH] 2.6.0-test4 -- add context switch counters

From: William Lee Irwin III
Date: Wed Aug 27 2003 - 02:51:47 EST


On Wed, Aug 27, 2003 at 05:39:27PM +1000, Peter Chubb wrote:
> Yes, the kernel is (supposed) to calculate the integral over time of
> the memory sizes; user space divides these integrals by elapsed time
> to get averages.
> To calculate these you need a timestamp for last change, and a set of
> counters.
> Then code to update all the counters every time one of the sizes
> change (otherwise you need a timestamp for each counter) by adding
> current_size*(current_time - last_change_time) to each counter.

At some point after saying the wrong thing I realized this.


William> The fault counters are vaguely bogus when threads are
William> involved. There's a comment alluding to that nearby.

On Wed, Aug 27, 2003 at 05:39:27PM +1000, Peter Chubb wrote:
> The fault counters are incorrect anyway --- faults satisfied from the
> page cache are counted as major faults, whereas we expect only faults
> that sleep for disk I/O to be counted as major faults.

Okay, we can handle that by pushing the counter ticking down far enough
we can actually tell whether io was done or not. In the meantime we're
reporting garbage.


William> This already has two counters in the task_t (no, I will not
William> use Finnish Hungarian notation in my general posts) that are
William> 100% unused. Probably the only thing preventing slab poison
William> from showing up there outright is the whole task_t copy in
William> kernel/fork.c and the bss zeroing for init_task.

On Wed, Aug 27, 2003 at 05:39:27PM +1000, Peter Chubb wrote:
> It's unclear what `swaps' are in Linux. Traditionally, this rusage
> field was the number of complete swapouts --- I'm not sure what the
> equivalent is when processes are not swapped out holus-bolus, but are
> paged gradually.

We don't have load control yet; the counters should probably be removed
until we do.


-- wli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/