linux-toradex.git/kernel/sched/cputime.c, branch v3.9.3

sched: Avoid prev->stime underflow

2013-05-19T18:38:19+00:00

commit 68aa8efcd1ab961e4684ef5af32f72a6ec1911de upstream.

Dave Hansen reported strange utime/stime values on his system:
https://lkml.org/lkml/2013/4/4/435

This happens because prev->stime value is bigger than rtime
value. Root of the problem are non-monotonic rtime values (i.e.
current rtime is smaller than previous rtime) and that should be
debugged and fixed.

But since problem did not manifest itself before commit
62188451f0d63add7ad0cd2a1ae269d600c1663d "cputime: Avoid
multiplication overflow on utime scaling", it should be threated
as regression, which we can easily fixed on cputime_adjust()
function.

For now, let's apply this fix, but further work is needed to fix
root of the problem.

Reported-and-tested-by: Dave Hansen 
Signed-off-by: Stanislaw Gruszka 
Cc: Frederic Weisbecker 
Cc: rostedt@goodmis.org
Cc: Linus Torvalds 
Cc: Dave Hansen 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/1367314507-9728-3-git-send-email-sgruszka@redhat.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

sched: Do not account bogus utime

2013-05-19T18:38:18+00:00

commit 772c808a252594692972773f6ee41c289b8e0b2a upstream.

Due to rounding in scale_stime(), for big numbers, scaled stime
values will grow in chunks. Since rtime grow in jiffies and we
calculate utime like below:

	prev->stime = max(prev->stime, stime);
	prev->utime = max(prev->utime, rtime - prev->stime);

we could erroneously account stime values as utime. To prevent
that only update prev->{u,s}time values when they are smaller
than current rtime.

Signed-off-by: Stanislaw Gruszka 
Cc: Frederic Weisbecker 
Cc: rostedt@goodmis.org
Cc: Linus Torvalds 
Cc: Dave Hansen 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/1367314507-9728-2-git-send-email-sgruszka@redhat.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

sched: Avoid cputime scaling overflow

2013-05-19T18:38:17+00:00

commit 55eaa7c1f511af5fb6ef808b5328804f4d4e5243 upstream.

Here is patch, which adds Linus's cputime scaling algorithm to the
kernel.

This is a follow up (well, fix) to commit
d9a3c9823a2e6a543eb7807fb3d15d8233817ec5 ("sched: Lower chances
of cputime scaling overflow") which commit tried to avoid
multiplication overflow, but did not guarantee that the overflow
would not happen.

Linus crated a different algorithm, which completely avoids the
multiplication overflow by dropping precision when numbers are
big.

It was tested by me and it gives good relative error of
scaled numbers. Testing method is described here:
http://marc.info/?l=linux-kernel&m=136733059505406&w=2

Originally-From: Linus Torvalds 
Signed-off-by: Stanislaw Gruszka 
Cc: Frederic Weisbecker 
Cc: rostedt@goodmis.org
Cc: Dave Hansen 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20130430151441.GC10465@redhat.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

sched: Lower chances of cputime scaling overflow

2013-05-19T18:38:17+00:00

commit d9a3c9823a2e6a543eb7807fb3d15d8233817ec5 upstream.

Some users have reported that after running a process with
hundreds of threads on intensive CPU-bound loads, the cputime
of the group started to freeze after a few days.

This is due to how we scale the tick-based cputime against
the scheduler precise execution time value.

We add the values of all threads in the group and we multiply
that against the sum of the scheduler exec runtime of the whole
group.

This easily overflows after a few days/weeks of execution.

A proposed solution to solve this was to compute that multiplication
on stime instead of utime:
   62188451f0d63add7ad0cd2a1ae269d600c1663d
   ("cputime: Avoid multiplication overflow on utime scaling")

The rationale behind that was that it's easy for a thread to
spend most of its time in userspace under intensive CPU-bound workload
but it's much harder to do CPU-bound intensive long run in the kernel.

This postulate got defeated when a user recently reported he was still
seeing cputime freezes after the above patch. The workload that
triggers this issue relates to intensive networking workloads where
most of the cputime is consumed in the kernel.

To reduce much more the opportunities for multiplication overflow,
lets reduce the multiplication factors to the remainders of the division
between sched exec runtime and cputime. Assuming the difference between
these shouldn't ever be that large, it could work on many situations.

This gets the same results as in the upstream scaling code except for
a small difference: the upstream code always rounds the results to
the nearest integer not greater to what would be the precise result.
The new code rounds to the nearest integer either greater or not
greater. In practice this difference probably shouldn't matter but
it's worth mentioning.

If this solution appears not to be enough in the end, we'll
need to partly revert back to the behaviour prior to commit
     0cf55e1ec08bb5a22e068309e2d8ba1180ab4239
     ("sched, cputime: Introduce thread_group_times()")

Back then, the scaling was done on exit() time before adding the cputime
of an exiting thread to the signal struct. And then we'll need to
scale one-by-one the live threads cputime in thread_group_cputime(). The
drawback may be a slightly slower code on exit time.

Signed-off-by: Frederic Weisbecker 
Cc: Stanislaw Gruszka 
Cc: Steven Rostedt 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Andrew Morton 
Signed-off-by: Stanislaw Gruszka 
Acked-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

sched/cputime: Fix accounting on multi-threaded processes

2013-04-08T15:40:52+00:00

Recent commit 6fac4829 ("cputime: Use accessors to read task
cputime stats") introduced a bug, where we account many times
the cputime of the first thread, instead of cputimes of all
the different threads.

Signed-off-by: Stanislaw Gruszka 
Acked-by: Frederic Weisbecker 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20130404085740.GA2495@redhat.com
Signed-off-by: Ingo Molnar

cputime: Use local_clock() for full dynticks cputime accounting

2013-02-24T11:57:16+00:00

Running the full dynticks cputime accounting with preemptible
kernel debugging trigger the following warning:

	[    4.488303] BUG: using smp_processor_id() in preemptible [00000000] code: init/1
	[    4.490971] caller is native_sched_clock+0x22/0x80
	[    4.493663] Pid: 1, comm: init Not tainted 3.8.0+ #13
	[    4.496376] Call Trace:
	[    4.498996]  [] debug_smp_processor_id+0xdb/0xf0
	[    4.501716]  [] native_sched_clock+0x22/0x80
	[    4.504434]  [] sched_clock+0x9/0x10
	[    4.507185]  [] fetch_task_cputime+0xad/0x120
	[    4.509916]  [] task_cputime+0x35/0x60
	[    4.512622]  [] acct_update_integrals+0x1e/0x40
	[    4.515372]  [] do_execve_common+0x4ff/0x5c0
	[    4.518117]  [] ? do_execve_common+0x144/0x5c0
	[    4.520844]  [] ? rest_init+0x160/0x160
	[    4.523554]  [] do_execve+0x37/0x40
	[    4.526276]  [] run_init_process+0x23/0x30
	[    4.528953]  [] kernel_init+0x9c/0xf0
	[    4.531608]  [] ret_from_fork+0x7c/0xb0

We use sched_clock() to perform and fixup the cputime
accounting. However we are calling it with preemption enabled
from the read side, which trigger the bug above.

To fix this up, use local_clock() instead. It takes care of
preemption and also provide a more reliable clock source. This
is welcome for this kind of statistic that is widely relied on
in userspace.

Reported-by: Thomas Gleixner 
Reported-by: Ingo Molnar 
Suggested-by: Thomas Gleixner 
Signed-off-by: Frederic Weisbecker 
Cc: Li Zhong 
Cc: Peter Zijlstra 
Cc: Steven Rostedt 
Cc: Kevin Hilman 
Link: http://lkml.kernel.org/r/1361636925-22288-3-git-send-email-fweisbec@gmail.com
Signed-off-by: Ingo Molnar

cputime: Remove irqsave from seqlock readers

2013-02-19T07:05:53+00:00

The reader side code has no requirement to disable interrupts while
sampling data. The sequence counter is enough to ensure consistency.

Signed-off-by: Thomas Gleixner 
Cc: Frederic Weisbecker 
Signed-off-by: Ingo Molnar

Merge tag 'full-dynticks-cputime-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks into sched/core

2013-02-05T12:10:33+00:00

Pull full-dynticks (user-space execution is undisturbed and
receives no timer IRQs) preparation changes that convert the
cputime accounting code to be full-dynticks ready,
from Frederic Weisbecker:

 "This implements the cputime accounting on full dynticks CPUs.

  Typical cputime stats infrastructure relies on the timer tick and
  its periodic polling on the CPU to account the amount of time
  spent by the CPUs and the tasks per high level domains such as
  userspace, kernelspace, guest, ...

  Now we are preparing to implement full dynticks capability on
  Linux for Real Time and HPC users who want full CPU isolation.
  This feature requires a cputime accounting that doesn't depend
  on the timer tick.

  To implement it, this new cputime infrastructure plugs into
  kernel/user/guest boundaries to take snapshots of cputime and
  flush these to the stats when needed. This performs pretty
  much like CONFIG_VIRT_CPU_ACCOUNTING except that context location
  and cputime snaphots are synchronized between write and read
  side such that the latter can safely retrieve the pending tickless
  cputime of a task and add it to its latest cputime snapshot to
  return the correct result to the user."

Signed-off-by: Frederic Weisbecker 
Signed-off-by: Ingo Molnar

cputime: Safely read cputime of full dynticks CPUs

2013-01-27T19:35:47+00:00

While remotely reading the cputime of a task running in a
full dynticks CPU, the values stored in utime/stime fields
of struct task_struct may be stale. Its values may be those
of the last kernel <-> user transition time snapshot and
we need to add the tickless time spent since this snapshot.

To fix this, flush the cputime of the dynticks CPUs on
kernel <-> user transition and record the time / context
where we did this. Then on top of this snapshot and the current
time, perform the fixup on the reader side from task_times()
accessors.

Signed-off-by: Frederic Weisbecker 
Cc: Andrew Morton 
Cc: Ingo Molnar 
Cc: Li Zhong 
Cc: Namhyung Kim 
Cc: Paul E. McKenney 
Cc: Paul Gortmaker 
Cc: Peter Zijlstra 
Cc: Steven Rostedt 
Cc: Thomas Gleixner 
[fixed kvm module related build errors]
Signed-off-by: Sedat Dilek

kvm: Prepare to add generic guest entry/exit callbacks

2013-01-27T19:35:40+00:00

Do some ground preparatory work before adding guest_enter()
and guest_exit() context tracking callbacks. Those will
be later used to read the guest cputime safely when we
run in full dynticks mode.

Signed-off-by: Frederic Weisbecker 
Cc: Andrew Morton 
Cc: Gleb Natapov 
Cc: Ingo Molnar 
Cc: Li Zhong 
Cc: Marcelo Tosatti 
Cc: Namhyung Kim 
Cc: Paul E. McKenney 
Cc: Paul Gortmaker 
Cc: Peter Zijlstra 
Cc: Steven Rostedt 
Cc: Thomas Gleixner