lkml.org 
[lkml]   [2008]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject[RFC 0/6] chargeback accounting patches
Date
Hi all,

I've taken Vaidy's patches to implement charge-back accounting and modified
them a bit. The end result is still mostly the same--scaled utime and stime
via taskstats--but hopefully done in a less invasive way. The point of these
patches is for a computer utilization accounting system to be able to determine
that a particular process was not completely CPU bound, at which point it could
try to determine if the process was memory-bound for (perhaps) more optimal
scheduling later. Or put discounts on the bill.

For sure, this is not to be used as a sole method for measuring processing
capacity. :)

There are six patches in this series. Allow me to summarize them:

1. First, there are accounting bugs in the cpufreq_stats code that will
be exposed by a later patch because someone assumed that cputime =
jiffies.

2. The second patch moves the APERF/MPERF access code into a separate
file so that both the chargeback accounting code and the acpi-cpufreq
driver can both access those MSRs without stepping on each other.

3. Next, we create a VIRT_CPU_ACCOUNTING config option. This enables us
to delegate timeslice accounting out of the generic kernel code into
arch-specific areas. In the arch-specific code, we can then use the
APERF/MPERF ratio to calculate the scaled utime/stime values. The
approach used is similar to what is done in arch/powerpc/ to scale
utime/stime values via SPURR/PURR.

4. Currently, x86 assumes that cputime = jiffies. However, this is an
integer counter, which means that fractional jiffies, such as what we
might get when trying to scale for CPU frequency, don't work. If
we change the cputime units to nanoseconds, however, we can accomplish
this without having to muck around with the taskstats code.

5. Convert the acpi-cpufreq driver to use the functions defined in patch 2
to access APERF/MPERF. Previously the acpi-cpufreq driver would zero
the MSRs after accessing them; however, this doesn't play well with
multiple accessors. Luckily, on a practical level the register is
wide enough that overflow won't happen for a long time.

6. Modify getdelays.c to report utime/stime/scaled_utime/scaled_stime.

Let me know what you think of the patchset. It's been tested with assorted
heavy/moderate loads and looks ok, though YMMV. I'm curious to see what
you all think... for one thing, this patchset doesn't stray too far away from
the notion that we charge 1 tick to the non-scaled utime/stime depending on
whichever space (user/system) we were in at the time of the tick. On one
hand that's still fairly close to the way we do things in x86 right now; on
the other hand, it's not terribly precise.

--D


\
 
 \ /
  Last update: 2008-11-25 22:49    [W:0.038 / U:0.260 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site