From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Andi Kleen <ak@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [patch] dubious process system time.
Date: Thu, 24 Aug 2006 15:28:23 +0200 [thread overview]
Message-ID: <1156426103.28464.29.camel@localhost> (raw)
In-Reply-To: <p731wr6fh54.fsf@verdi.suse.de>
On Thu, 2006-08-24 at 14:32 +0200, Andi Kleen wrote:
> > The system time that is accounted to a process includes the time spent
> > in three different contexts: normal system time, hardirq time and
> > softirq time. To account hardirq time and sortirq time to a process
> > seems wrong, because the process could just happen to run when the
> > interrupt arrives that was caused by an i/o for a completly different
> > process. And the sum over stime and cstime of all processes won't
> > match cputstat->system either.
> > The following patch changes the accounting of system time so that
> > hardirq and softirq time are not accounted to a process anymore.
>
> So where does it get accounted then? It has to be accounted somewhere.
> Sounds like a quite radical change to me, might break a lot of
> existing assumptions.
At the moment hardirq+softirq is just added to a random process, in
general this is completely wrong. You just need a system with a cpu hog
and an i/o bound process and you get queer results.
To add hardirq+softirq to a single process is wrong to begin with, for
that you would need to be able to identify the process that caused the
i/o. And if two processes require a single file page then what? Split
the time required to load the page to two processes? Not really. The
conclusion is that hardirq+softirq time should not be accouted to any
process. It is accounted globally in cpustat->softirq and
cpustat->hardirq.
There is one assumption that would break by the change: that the sum of
the hardirq and softirq time is contained in the sum of the stime and
cstime fields of all processes. I don't think that this is relevant.
--
blue skies,
Martin.
Martin Schwidefsky
Linux for zSeries Development & Services
IBM Deutschland Entwicklung GmbH
"Reality continues to ruin my life." - Calvin.
next prev parent reply other threads:[~2006-08-24 13:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-24 12:18 [patch] dubious process system time Martin Schwidefsky
2006-08-24 12:32 ` Andi Kleen
2006-08-24 13:28 ` Martin Schwidefsky [this message]
2006-08-24 15:18 ` Andi Kleen
2006-08-24 16:02 ` Martin Schwidefsky
2006-08-25 10:12 ` Helge Hafting
2006-08-25 10:29 ` Martin Schwidefsky
2006-08-25 12:58 ` Paul Mackerras
2006-08-24 23:40 ` Paul Mackerras
2006-08-25 8:18 ` Martin Schwidefsky
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=1156426103.28464.29.camel@localhost \
--to=schwidefsky@de.ibm.com \
--cc=ak@suse.de \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.