public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: William Lee Irwin III <wli@holomorphy.com>
To: mfedyk@matchmail.com
Cc: Andrew Morton <akpm@osdl.org>,
	Peter Chubb <peterc@gelato.unsw.edu.au>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 2.6.0-test4 -- add context switch counters
Date: Wed, 27 Aug 2003 00:16:48 -0700	[thread overview]
Message-ID: <20030827071648.GY1715@holomorphy.com> (raw)
In-Reply-To: <20030827012914.GB5280@matchmail.com>

Mike, your MUA sucks; you unwittingly removed yourself from Reply-To:


On Tue, Aug 26, 2003 at 06:29:14PM -0700, Mike Fedyk wrote:
> Command exited with non-zero status 100
> 	Command being timed: "apt-get update"
> 	User time (seconds): 0.01
> 	System time (seconds): 0.00
> 	Percent of CPU this job got: 6%
> 	Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.32
> 	Average shared text size (kbytes): 0
> 	Average unshared data size (kbytes): 0
> 	Average stack size (kbytes): 0
> 	Average total size (kbytes): 0
> The averages might be nice...

The averages themselves aren't reported with getrusage(), only direct
usage measurements. Presumably luserspace computes the averages itself.
i.e. the counters are all for non-average versions of these stats and
(because we're seeing all 0's) are not reported at all.


On Tue, Aug 26, 2003 at 06:29:14PM -0700, Mike Fedyk wrote:
> 	Maximum resident set size (kbytes): 0
> But the maximum would allow any polling app to do its polling less often.
> As well as the averages above...
> 	Average resident set size (kbytes): 0
> 	Major (requiring I/O) page faults: 320
> 	Minor (reclaiming a frame) page faults: 21

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


On Tue, Aug 26, 2003 at 06:29:14PM -0700, Mike Fedyk wrote:
> 	Voluntary context switches: 0
> How can you have voluntary context switches in a preemptive environment?
> 	Involuntary context switches: 0

Irrelevant to CONFIG_PREEMPT; preemptive multitasking (i.e. userspace can
be preempted) as UNIX has always done is the important issue here.


On Tue, Aug 26, 2003 at 06:29:14PM -0700, Mike Fedyk wrote:
> 	Swaps: 0
> Counting swaps would be nice too.	

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


On Tue, Aug 26, 2003 at 06:29:14PM -0700, Mike Fedyk wrote:
> 	File system inputs: 0
> 	File system outputs: 0
> 	Socket messages sent: 0
> 	Socket messages received: 0
> 	Signals delivered: 0
> Yes, yes, yes.

These would be easy to set up, they just need counters and the ticking
of the counters dropped in.


On Tue, Aug 26, 2003 at 06:29:14PM -0700, Mike Fedyk wrote:
>      	Page size (bytes): 4096
> 	Exit status: 100
> One more thing:
> $ cat /proc/meminfo 
> MemTotal:       320628 kB
> MemFree:          5148 kB
> Buffers:          8316 kB
> Where'd shared go, and why didn't rmap start populating this value?  It
> should be there in the pte-chain lists...

Shared isn't particularly useful as a single value unqualified by
sharing level.


On Tue, Aug 26, 2003 at 06:29:14PM -0700, Mike Fedyk wrote:
> Cached:         127140 kB
> SwapCached:          0 kB
> Active:         266212 kB
> Inactive:        10608 kB
> HighTotal:           0 kB
> HighFree:            0 kB
> Why is high(total|free) there in a non-highmem kernel?  If this file were
> more dynamic, then we wouldn't have apps that counted on the line number
> instead of the first colum's value...
> Ok, so that was two more... ;)

They could probably very well be omitted; in all likelihood just making
the format more resistant to .config changes to make luserspace's life
easier is a good reason to keep it there.


-- wli

  parent reply	other threads:[~2003-08-27  7:15 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-27  0:57 [PATCH] 2.6.0-test4 -- add context switch counters Peter Chubb
2003-08-27  1:18 ` Andrew Morton
2003-08-27  1:29   ` Mike Fedyk
2003-08-27  1:52     ` Peter Chubb
2003-08-27  7:16     ` William Lee Irwin III [this message]
2003-08-27  7:39       ` Peter Chubb
2003-08-27  7:51         ` William Lee Irwin III
2003-08-28 16:55           ` Mike Fedyk
2003-08-28 17:07             ` William Lee Irwin III
2003-08-28 17:09             ` William Lee Irwin III
2003-08-28 17:48               ` Mike Fedyk
2003-08-27  8:10         ` William Lee Irwin III
2003-08-27  1:50   ` Peter Chubb
2003-08-27  7:26     ` William Lee Irwin III
2003-11-18  1:18       ` William Lee Irwin III
2003-08-27 14:41   ` bert hubert
2003-08-27  6:54 ` William Lee Irwin III
2003-08-27 15:52   ` Larry McVoy
2003-08-27 16:01     ` William Lee Irwin III
2003-08-27 16:09       ` Larry McVoy
2003-08-27 17:57         ` William Lee Irwin III

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030827071648.GY1715@holomorphy.com \
    --to=wli@holomorphy.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mfedyk@matchmail.com \
    --cc=peterc@gelato.unsw.edu.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox