flashcache: fix scheduler switch panic bug

After applied "multi request list" patches for flashcache, when calling blk_get_rl and the
scheduler is switching right now, it will get a 'dead' request-list, so we add condition
to fetch root_rl when io-scheduler is switching.

Signed-off-by: Robin Dong <sanbai@taobao.com>
tpps: add new io-scheduler 'tpps' mainly from cfq code

We want to use blkio.cgroup on high-speed device (like fusionio) for our mysql clusters.
After testing different io-scheduler, we found that  cfq is too slow and deadline can't run on cgroup.
So we developed a new io-scheduler: tpps (Tiny Parallel Proportion Scheduler).It dispatch requests
only by using their individual weight and total weight (proportion) therefore it's simply and efficient.

The main code framework of tpps is from cfq.

Test case: fusionio card, 4 cgroups, iodepth-512

groupname  weight
test1      1000
test2      800
test3      600
test4      400

Use tpps, the result is:

groupname  iops    avg-rt(ms)   max-rt(ms)
test1      30220   16           54
test2      28261   18           56
test3      26333   19           69
test4      20152   25           87

Use cfq, the result is:

groupname  iops    avg-rt(ms)   max-rt(ms)
test1      16478   30           242
test2      13015   39           347
test3       9300   54           371
test4       5806   87           393

Signed-off-by: Robin Dong <sanbai@taobao.com>
tpps: add new func tpps_forced_dispatch()

Add new func tpps_forced_dispatch() to dispatch all requests forcely.
Without this dmesg will report warning.

Signed-off-by: Robin Dong <sanbai@taobao.com>
tpps: update weight of group timely

Update the group's weight before compute quota of a group in tpps_dispatch_request()
for dispatching precisely.

Signed-off-by: Robin Dong <sanbai@taobao.com>
tpps: add new blkio_policy_type for tpps

Add new blkio_policy_type with plid equaling to "BLKIO_POLICY_TPPS" so
the blkcg_get_weight could get right 'weight' value.

Signed-off-by: Robin Dong <sanbai@taobao.com>
tpps: add new members in struct io_context for new scheduler

Add new radix_tree and tic_data in struct io_context for tpps to avoid
conflict between cfq and tpps when useing context structure of io.

Signed-off-by: Robin Dong <sanbai@taobao.com>
tpps: add check before tpps_del_queue()

We found panic on BUG_ON(tppg->nr_tppq < 1) in pressure-testing.
After long term (about one month) tracing we finally find out the reason: some scsi_cmds
passed from scsi_ioctl will call blk_execute_rq_nowait and call tpps_set_request() but
never call tpps_insert_request() (It even doesn't get into io-scheduler) so the counter
of nr_tppq gets wrong.
To fix it, we add check before calling tpps_del_queue() and for making it safer, adding
check before BUG_ON() to report more information.

Signed-off-by: Robin Dong <sanbai@taobao.com>
fix task starttime in container

Patch-mainline: inhouse
References:

task's starttime = time_since_1970 - time_since_boot +
                   (task_start_time - wall_to_monotonic) / HZ

Time_since_boot is the time reading from /proc/uptime, which
fixed in patch fix-uptime-in-container.patch to real uptime in
container. In order to get right task starttime in container,
task_start_time should be fix to 'task_start_time - init_task->start_time'.

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

fix task starttime in container
Merge pull request #13 from RobinDong/dev

Add new io-scheduler tpps
disk-bind: pass slot and phynum from mpt2sas driver to sd_probe()

The mpt2sas driver could get slot and phynum from SAS-card, so we
could pass it to sd_probe() by sdev_gendev.

Signed-off-by: Robin Dong <sanbai@taobao.com>
disk-bind: call ext4_free_io_end() even with io error

If the ext4_convert_unwritten_extents() returns an error,
we no longer keep the end_io structure on the linked list.
This doesn't help, because it tends to lock up the file system and wedges
the system.  That's one way to call attention to the problem, but it
doesn't help the overall robustness of the system.

Part of the patch comes from http://kernel.opensuse.org/cgit/kernel/commit/?id=b82e384c7b

Signed-off-by: Robin Dong <sanbai@taobao.com>
Revert "fix task starttime in container"

This reverts commit 1bd4cd3b973fd046e547f3c51b209e5de7f79edb
since this patch is rebased to master, not dev.
Merge pull request #16 from RobinDong/dev

Dev
Update README.markdown.

Signed-off-by: Tao Ma <boyu.mt@taobao.com>
[PATCH] cputime: Avoid multiplication overflow on utime scaling

upstream commit 62188451f0d63add7ad0cd2a1ae269d600c1663d

We scale stime, utime values based on rtime (sum_exec_runtime
converted to jiffies). During scaling we multiple rtime * utime,
which seems to be fine, since both values are converted to u64,
but it's not.

Let assume HZ is 1000 - 1ms tick. Process consist of 64 threads,
run for 1 day, threads utilize 100% cpu on user space. Machine
has 64 cpus.

Process rtime = utime will be 64 * 24 * 60 * 60 * 1000 jiffies,
which is 0x149970000. Multiplication rtime * utime result is
0x1a855771100000000, which can not be covered in 64 bits.

Result of overflow is stall of utime values visible in user
space (prev_utime in kernel), even if application still consume
lot of CPU time.

A solution to solve this is to perform the multiplication on
stime instead of utime. It's easy to grow the utime value fast
with a CPU bound thread in userspace for example. Now we assume
that doing so with stime is much harder. In most cases a task
shouldn't ever spend much time in kernel space as it tends to
sleep waiting for jobs completion when they take long to
achieve. IO is the typical example of that.

Hence scaling the cputime by performing the multiplication on
stime instead of utime should considerably reduce the chances of
an overflow on most workloads.

This is largely inspired by a patch from Stanislaw Gruszka:
http://lkml.kernel.org/r/20130107113144.GA7544@redhat.com

Inspired-by: Stanislaw Gruszka <sgruszka@redhat.com>
Reported-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/r/1359217182-25184-1-git-send-email-fweisbec@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Charles Wang <muming.wq@taobao.com>
[PATCH] sched: Lower chances of cputime scaling overflow

upstream commit d9a3c9823a2e6a543eb7807fb3d15d8233817ec5

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 <fweisbec@gmail.com>
Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Charles Wang <muming.wq@taobao.com>
[PATCH] sched: Do not account bogus utime

upstream commit: 772c808a252594692972773f6ee41c289b8e0b2a

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 <sgruszka@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: rostedt@goodmis.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dave Hansen <dave@sr71.net>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1367314507-9728-2-git-send-email-sgruszka@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Charles Wang <muming.wq@taobao.com>
[PATCH] sched: Avoid prev->stime underflow

upstream commit 68aa8efcd1ab961e4684ef5af32f72a6ec1911de

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 <dave@sr71.net>
Cc: <stable@vger.kernel.org> # 3.9+
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: rostedt@goodmis.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dave Hansen <dave@sr71.net>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1367314507-9728-3-git-send-email-sgruszka@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Charles Wang <muming.wq@taobao.com>
[PATCH] sched/cputime: Do not scale when utime == 0

upstream commit 5a8e01f8fa51f5cbce8f37acc050eb2319d12956

scale_stime() silently assumes that stime < rtime, otherwise
when stime == rtime and both values are big enough (operations
on them do not fit in 32 bits), the resulting scaling stime can
be bigger than rtime. In consequence utime = rtime - stime
results in negative value.

User space visible symptoms of the bug are overflowed TIME
values on ps/top, for example:

 $ ps aux | grep rcu
 root         8  0.0  0.0      0     0 ?        S    12:42   0:00 [rcuc/0]
 root         9  0.0  0.0      0     0 ?        S    12:42   0:00 [rcub/0]
 root        10 62422329  0.0  0     0 ?        R    12:42 21114581:37 [rcu_preempt]
 root        11  0.1  0.0      0     0 ?        S    12:42   0:02 [rcuop/0]
 root        12 62422329  0.0  0     0 ?        S    12:42 21114581:35 [rcuop/1]
 root        10 62422329  0.0  0     0 ?        R    12:42 21114581:37 [rcu_preempt]

or overflowed utime values read directly from /proc/$PID/stat

Reference:

  https://lkml.org/lkml/2013/8/20/259

Reported-and-tested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: stable@vger.kernel.org
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Borislav Petkov <bp@alien8.de>
Link: http://lkml.kernel.org/r/20130904131602.GC2564@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Charles Wang <muming.wq@taobao.com>