From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>,
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, 26 May 2008 22:54:43 +0530 [thread overview]
Message-ID: <483AF25B.6090806@linux.vnet.ibm.com> (raw)
In-Reply-To: <20080526085000.33787eac@infradead.org>
Arjan van de Ven wrote:
> On Mon, 26 May 2008 20:01:33 +0530
> Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> wrote:
>
>> The following RFC patch tries to implement scaled CPU utilisation
>> statistics using APERF and MPERF MSR registers in an x86 platform.
>>
>> The CPU capacity is significantly changed when the CPU's frequency is
>> reduced for the purpose of power savings. The applications that run
>> at such lower CPU frequencies are also accounted for real CPU time by
>> default. If the applications have been run at full CPU frequency,
>> they would have finished the work faster and not get charged for
>> excessive CPU time.
>>
>> One of the solution to this problem it so scale the utime and stime
>> entitlement for the process as per the current CPU frequency. This
>> technique is used in powerpc architecture with the help of hardware
>> registers that accurately capture the entitlement.
>>
>
> there are some issues with this unfortunately, and these make it
> a very complex thing to do.
> Just to mention a few:
> 1) What if the BIOS no longer allows us to go to the max frequency for
> a period (for example as a result of overheating); with the approach
> above, the admin would THINK he can go faster, but he cannot in reality,
> so there's misleading information (the system looks half busy, while in
> reality it's actually the opposite, it's overloaded). Management tools
> will take the wrong decisions (such as moving MORE work to the box, not
> less)
> 2) On systems with Intel Dynamic Acceleration technology, you can get
> over 100% of cycles this way. (For those who don't know what IDA is;
> IDA is basically a case where if your Penryn based dual core laptop is
> only using 1 core, the other core can go faster than 100% as long as
> thermals etc allow it). How do you want to deal with this?
Arjan,
These problems exist anyway, irrespective of scaled accounting (I'd say that
they are exceptions)
1. The management tool does have access to the current frequency and maximum
frequency, irrespective of scaled accounting. The decision could still be taken
on the data that is already available and management tools can already use them
2. With IDA, we'd have to document that APERF/MPERF can be greater than 100% if
the system is overclocked.
Scaled accounting only intends to provide data already available. Interpretation
is left to management tools and we'll document the corner cases that you just
mentioned.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
next prev parent reply other threads:[~2008-05-26 17:29 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-26 14:31 [RFC PATCH v1 0/3] Scaled statistics using APERF/MPERF in x86 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 [this message]
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
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=483AF25B.6090806@linux.vnet.ibm.com \
--to=balbir@linux.vnet.ibm.com \
--cc=aarora@linux.vnet.ibm.com \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mikey@neuling.org \
--cc=suresh.b.siddha@intel.com \
--cc=svaidy@linux.vnet.ibm.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