[PATCH] sched/debug: Take PID namespace into account

upstream commit fc840914e9b07ab4685c195e1e54e58de4f84c03

Emmanuel reported that /proc/sched_debug didn't report the right PIDs
when using namespaces, cure this.

Reported-by: Emmanuel Deloget <emmanuel.deloget@efixo.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20130909110141.GM31370@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Charles Wang <muming.wq@taobao.com>
t4: two fixes for instance-ware loadavg

1. instance's runq in /proc/loadavg is still global, change it to instance's internal number.
2. Do not reset global counter 'avenrun'. Here it's intent to initialize cpuacct's avenrun,
but no need since we already use kzalloc. The bug has effect on global loadavg while
new cpuacct cgroup is created.


Signed-off-by: Sha Zhengju <handai.szj@taobao.com>
Merge pull request #26 from shazj99/t4_loadavg

t4: two fixes for instance-ware loadavg
[PATCH] sched: Avoid throttle_cfs_rq racing with period_timer stopping

 upstream commit: f9f9ffc237dd924f048204e8799da74f9ecf40cf

sched: Avoid throttle_cfs_rq() racing with period_timer stopping

throttle_cfs_rq() doesn't check to make sure that period_timer is running,
and while update_curr/assign_cfs_runtime does, a concurrently running
period_timer on another cpu could cancel itself between this cpu's
update_curr and throttle_cfs_rq(). If there are no other cfs_rqs running
in the tg to restart the timer, this causes the cfs_rq to be stranded
forever.

Fix this by calling __start_cfs_bandwidth() in throttle if the timer is
inactive.

(Also add some sched_debug lines for cfs_bandwidth.)

Tested: make a run/sleep task in a cgroup, loop switching the cgroup
between 1ms/100ms quota and unlimited, checking for timer_active=0 and
throttled=1 as a failure. With the throttle_cfs_rq() change commented out
this fails, with the full patch it passes.

Signed-off-by: Ben Segall <bsegall@google.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: pjt@google.com
Link: http://lkml.kernel.org/r/20131016181632.22647.84174.stgit@sword-of-the-dawn.mtv.corp.google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Charles Wang <muming.wq@taobao.com>
Merge pull request #27 from CharlesWang/dev-sched

Dev sched
[PATCH] fix sched-debug-Take-PID-namespace-into-account.patch

  Bad backport :<. The argument passing for task_pid_nr should
be 'struct task_struct *', not 'pid_t'.

Signed-off-by: Charles Wang <muming.wq@taobao.com>
Merge pull request #28 from CharlesWang/dev-sched

[PATCH] fix sched-debug-Take-PID-namespace-into-account.patch
[PATCH] sched: fix divide_error panic in task_times

divide_error happens when sum_exec_runtime < 1ms and stime +
utime > 0. Then rtime will be zero, and in scale_stime 
rtime < total. total / rtime will execute, and then panic!!

Fix this by checking prev->stime + prev->utime >= rtime first. 

Base patch is:
 from Frederic Weisbecker <fweisbec@gmail.com>
 subject: [PATCH] cputime: Consolidate cputime adjustment code
 upstream commit: d37f761dbd276790f70dcf73a287fde2c3464482

task_cputime_adjusted() and thread_group_cputime_adjusted()
essentially share the same code. They just don't use the same
source:

* The first function uses the cputime in the task struct and the
previous adjusted snapshot that ensures monotonicity.

* The second adds the cputime of all tasks in the group and the
previous adjusted snapshot of the whole group from the signal
structure.

Just consolidate the common code that does the adjustment. These
functions just need to fetch the values from the appropriate
source.

Backport Notes:
	Patch below has alread been overridded. So skip it. 

	commit: bea6832cc8c4a0a9a65dd17da6aaa657fe27bc3e
	subject: sched: fix divide by zero at {thread_group,task}_times

Signed-off-by: Charles Wang <muming.wq@taobao.com>
[PATCH] sched: Avoid cputime scaling overflow

upstream commit 55eaa7c1f511af5fb6ef808b5328804f4d4e5243

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

Backport Note:
	Here another patch is merged:

	sched: Use swap() macro in scale_stime()
	84f9f3a15611536537d59060818a2354d5039ff3

Originally-From: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: rostedt@goodmis.org
Cc: Dave Hansen <dave@sr71.net>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20130430151441.GC10465@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Charles Wang <muming.wq@taobao.com>
Merge pull request #29 from CharlesWang/dev-sched

Dev sched