[PATCH 9/9] ia64: VIRT_CPU_ACCOUNTING (accurate cpu time accounting)

[PATCH 9/9] ia64: VIRT_CPU_ACCOUNTING (accurate cpu time accounting)

[Hidetoshi Seto]

> [9/9] ia64_acct_get_vtime.patch

Now all check points are ready.

We already cumulate cycles for stime/utime on kernel
entrance/exit, so what we need to do is reflecting them
into stime/utime of the thread, after translating cycles
to nsec.

As I already mentioned, this reflection are required to
be done in:

 - context switch
 - account_system_vtime()
    - irq_enter
    - irq_exit
    - softirq entrance
    - softirq exit

From these points, we add calls of followings:
　account_system_time()
　account_user_time()
to reflect the state-transition based cpu time.
And beside of this, we delete these calls from timer_interrupt
not to reflect the tick-sampling based cpu time.

After all, we get feature of VIRT_CPU_ACCOUNTING on ia64.

Thanks,
H.Seto

Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>

---
 arch/ia64/kernel/time.c |   47 ++++++++++++++++++++++++++++++++++++++++++-----
 1 files changed, 42 insertions(+), 5 deletions(-)

Index: linux-2.6.23/arch/ia64/kernel/time.c
=================================--- linux-2.6.23.orig/arch/ia64/kernel/time.c
+++ linux-2.6.23/arch/ia64/kernel/time.c
@@ -64,9 +64,32 @@
 #include <linux/kernel_stat.h>
 #include <linux/posix-timers.h>

+#define cycle_to_cputime(cyc)	\
+  (cputime_t)(((cyc)*local_cpu_data->nsec_per_cyc) >> IA64_NSEC_PER_CYC_SHIFT)
+
 void ia64_account_on_switch(struct task_struct *prev, struct task_struct *next)
 {
+	struct thread_info *pi = task_thread_info(prev);
+	struct thread_info *ni = task_thread_info(next);
+	unsigned long flags;
+	__u64 now;
+
+	local_irq_save(flags);
+
+	now = ia64_get_itc();
+
+	account_system_time(prev, 0,
+			cycle_to_cputime(pi->ac_stime + (now - pi->ac_stamp)));
+	pi->ac_stime = 0;
+
+	if (pi->ac_utime) {
+		account_user_time(prev, cycle_to_cputime(pi->ac_utime));
+		pi->ac_utime = 0;
+	}
+
+	pi->ac_stamp = ni->ac_stamp = now;

+	local_irq_restore(flags);
 }

 /*
@@ -75,7 +98,26 @@
  */
 void account_system_vtime(struct task_struct *tsk)
 {
+	struct thread_info *ti = task_thread_info(tsk);
+	unsigned long flags;
+	__u64 now;
+
+	local_irq_save(flags);
+
+	now = ia64_get_itc();
+
+	account_system_time(tsk, 0,
+			cycle_to_cputime(ti->ac_stime + (now - ti->ac_stamp)));
+	ti->ac_stime = 0;
+
+	if (ti->ac_utime) {
+		account_user_time(tsk, cycle_to_cputime(ti->ac_utime));
+		ti->ac_utime = 0;
+	}
+
+	ti->ac_stamp = now;

+	local_irq_restore(flags);
 }

 /*
@@ -87,11 +129,6 @@
 	struct task_struct *p = current;
 	int cpu = smp_processor_id();

-	/* Note: this timer irq context must be accounted for as well. */
-	if (user_tick)
-		account_user_time(p, jiffies_to_cputime(1));
-	else
-		account_system_time(p, HARDIRQ_OFFSET, jiffies_to_cputime(1));
 	run_local_timers();
 	if (rcu_pending(cpu))
 		rcu_check_callbacks(cpu, user_tick);

Re: [PATCH 9/9] ia64: VIRT_CPU_ACCOUNTING (accurate cpu time accounting)

[Peter Chubb]

>>>>> "Hidetoshi" = Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> writes:

>> [9/9] ia64_acct_get_vtime.patch
Hidetoshi> Now all check points are ready.

Hidetoshi> We already cumulate cycles for stime/utime on kernel
Hidetoshi> entrance/exit, so what we need to do is reflecting them
Hidetoshi> into stime/utime of the thread, after translating cycles to
Hidetoshi> nsec.

This patchset duplicates some of the Microstate Accounting patchset
(which attempts to keep track of time spent in various states for each
thread).  As such I've had some experience trying to do this stuff.
  Things to watch are:
 -- With Montvale and later, the processor clock speed can be
    varied via ACPI.  Does ITC rate change?  In additon, KVM can
    virtualise ITC (although it doesn't at present)
 -- ITC is not synchronised across multiple processors.  I don't think
    this'll be an issue for you as you're only measuring time on-cpu,
    and migration necessarily goes via a run queue.
 -- Adding ACCOUNT_SYS_ENTER adds around 40 cycles to the system
    call path.  If you wanted, you could move reading ITC earlier (it
    takes up to 36 cycles), and overlap with other work.

Peter C
--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
http://www.ertos.nicta.com.au           ERTOS within National ICT Australia

Re: [PATCH 9/9] ia64: VIRT_CPU_ACCOUNTING (accurate cpu time accounting)

[peterc]

>>>>> "Peter" = Peter Chubb <peterc@gelato.unsw.edu.au> writes:

>>>>> "Hidetoshi" = Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> writes:
>>> [9/9] ia64_acct_get_vtime.patch
Peter> trying to do this stuff.  Things to watch are: -- With Montvale
Peter> and later, the processor clock speed can be varied via ACPI.
Peter> Does ITC rate change?  

I've checked ... according to the latest IA-64 System Architecture,
ITC runs at constant rate even if the instruction execution rate
changes.  So you're safe.

--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
http://www.ertos.nicta.com.au           ERTOS within National ICT Australia

Re: [PATCH 9/9] ia64: VIRT_CPU_ACCOUNTING (accurate cpu time accounting)

[Hidetoshi Seto]

Peter Chubb wrote:
> This patchset duplicates some of the Microstate Accounting patchset
> (which attempts to keep track of time spent in various states for each
> thread).  As such I've had some experience trying to do this stuff.

Google is kind enough to tell me how was your Microstate Accounting
patchset. Both of yours and mine intended to implement a state-transition
based accounting to get more accurate cpu time. It is common point.

The differences are origin (maybe msa is from Solaris, right?), targeting
arch (sys_msa aimed at multiple archs, but my patchset touches ia64 only),
and actual achievement on linux (completely new vs proven on IBM archs).

>   Things to watch are:
>  -- With Montvale and later, the processor clock speed can be
>     varied via ACPI.  Does ITC rate change?  In additon, KVM can
>     virtualise ITC (although it doesn't at present)

The factors for cycle-to-nsec translation are treated as per-cpu data.
Thus it would not be problem if processor clocks are varied at boot.

I'm not sure whether the clocks can be changed while running or not.
If it can, at least it will also affect sched_clock(), and god knows
who will work for the problem...

>  -- ITC is not synchronised across multiple processors.  I don't think
>     this'll be an issue for you as you're only measuring time on-cpu,
>     and migration necessarily goes via a run queue.

Yes, it doesn't matter. I don't compare cycles from different cpus.

>  -- Adding ACCOUNT_SYS_ENTER adds around 40 cycles to the system
>     call path.  If you wanted, you could move reading ITC earlier (it
>     takes up to 36 cycles), and overlap with other work.

Indeed. It is worth to do.

Thanks,
H.Seto

> Peter C
> --
> Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
> http://www.ertos.nicta.com.au           ERTOS within National ICT Australia
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>