mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>,
	Arjan van de Ven <arjan@infradead.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	venkatesh.pallipadi@intel.com, suresh.b.siddha@intel.com,
	Michael Neuling <mikey@neuling.org>,
	"Amit K. Arora" <aarora@linux.vnet.ibm.com>
Subject: Re: [RFC PATCH v1 0/3] Scaled statistics using APERF/MPERF in x86
Date: Mon, 2 Jun 2008 23:24:00 +0530	[thread overview]
Message-ID: <20080602175400.GN5504@dirshya.in.ibm.com> (raw)
In-Reply-To: <20080531212709.GA6757@ucw.cz>

* Pavel Machek <pavel@ucw.cz> [2008-05-31 23:27:10]:

> Hi!
> 
> > > without knowing anything else than this, then yes that would be a
> > > logical conclusion: the most likely cause would be because your cpu is
> > > memory bound. In fact, you could then scale down your cpu
> > > frequency/voltage to be lower, and save some power without losing
> > > performance. 
> > > It's a weird workload though, its probably a time based thing where you
> > > alternate between idle and fully memory bound loads.
> > > 
> > > (which is another case where your patches would then expose idle time
> > > even though your cpu is fully utilized for the 50% of the time it's
> > > running)
> > 
> > We expect the end user to see 50% as scaled utilization and 100% as normal
> > utilization. We don't intend to remove tsk->utime and tsk->stime. Our patches
> > intend to provide the data and not impose what control action should be taken.
> 
> Aha, ok, forget about my regression comments.
> 
> Still, what you want to do seems hard. What if cpu is running at max
> frequency but memory is not? What if cpu and memory is running at max
> frequency but frontside bus is not?

uh... you made the scope of the problem bigger :)
If we take into consideration various system parameters like memory,
fsb that we can control to save power, then this scaling factor is not
accurate.

> You want some give_me_bogomips( cpu freq, mem freq, fsb freq ) function,
> but that depends on workload, so it is impossible to do...

Isn't this a good problem to solve :)

Lets start adding parameters in steps to make the scaled statistics
accurate.  We want to start with cpu and see if we can provide
a reasonable solution.

Workload variation is outside the scope since we are estimating how
much cpu was provided to the application or workload. The fact that
the workload could not utilise them effectively is not an accounting
problem.  Accounting the exact cpu resource that an application used
is a performance feedback problem which can potentially be derived
from accounting.

--Vaidy

  reply	other threads:[~2008-06-02 17:52 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-26 14:31 Vaidyanathan Srinivasan
2008-05-26 14:31 ` [RFC PATCH v1 1/3] General framework for APERF/MPERF access and accounting Vaidyanathan Srinivasan
2008-05-26 18:11   ` Balbir Singh
2008-05-27 14:54     ` Vaidyanathan Srinivasan
2008-05-26 14:31 ` [RFC PATCH v1 2/3] Make calls to account_scaled_stats Vaidyanathan Srinivasan
2008-05-26 18:18   ` Balbir Singh
2008-05-27 15:02     ` Vaidyanathan Srinivasan
2008-05-29 15:18   ` Michael Neuling
2008-05-29 18:23     ` Vaidyanathan Srinivasan
2008-05-26 14:31 ` [RFC PATCH v1 3/3] Print scaled utime and stime in getdelays Vaidyanathan Srinivasan
2008-05-26 15:50 ` [RFC PATCH v1 0/3] Scaled statistics using APERF/MPERF in x86 Arjan van de Ven
2008-05-26 17:24   ` Balbir Singh
2008-05-26 18:00     ` Arjan van de Ven
2008-05-26 18:36       ` Balbir Singh
2008-05-26 18:51         ` Arjan van de Ven
2008-05-27 12:59           ` Balbir Singh
2008-05-27 13:19             ` Vaidyanathan Srinivasan
2008-05-27 14:15               ` Arjan van de Ven
2008-05-27 15:27                 ` Vaidyanathan Srinivasan
2008-05-31 21:27             ` Pavel Machek
2008-06-02 17:54               ` Vaidyanathan Srinivasan [this message]
2008-06-03  2:20                 ` Arjan van de Ven
2008-05-27 13:29           ` Vaidyanathan Srinivasan
2008-05-27 14:19             ` Arjan van de Ven
2008-05-27 15:20               ` Vaidyanathan Srinivasan
2008-05-27 14:04   ` Vaidyanathan Srinivasan
2008-05-27 16:40     ` Arjan van de Ven
2008-05-27 18:26       ` Vaidyanathan Srinivasan
2008-05-31 21:17     ` Pavel Machek
2008-05-31 21:13   ` Pavel Machek
2008-06-02  6:08     ` Balbir Singh

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=20080602175400.GN5504@dirshya.in.ibm.com \
    --to=svaidy@linux.vnet.ibm.com \
    --cc=aarora@linux.vnet.ibm.com \
    --cc=arjan@infradead.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikey@neuling.org \
    --cc=pavel@ucw.cz \
    --cc=suresh.b.siddha@intel.com \
    --cc=venkatesh.pallipadi@intel.com \
    /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

all inboxes | Powered by JetHome®