Hi Christoph,
在 2021/1/28 星期四 下午 5:10, Dongsheng Yang 写道:
Hi Christop:
在 2021/1/28 星期四 上午 1:37, Christoph Hellwig 写道:
But the old code is also completely broken. We can't just OR in
the op, as that implicitly assumes the old op was 0 (REQ_OP_READ).
Yes, indeed, there is an assume tha
Hi Christop:
在 2021/1/28 星期四 上午 1:37, Christoph Hellwig 写道:
But the old code is also completely broken. We can't just OR in
the op, as that implicitly assumes the old op was 0 (REQ_OP_READ).
Yes, indeed, there is an assume that the op is just possible to be 0
(REQ_OP_READ) or 1 (REQ_OP_WRIT
在 2021/1/26 星期二 下午 12:34, Coly Li 写道:
On 1/26/21 12:32 PM, Dongsheng Yang wrote:
在 2021/1/25 星期一 下午 12:53, Coly Li 写道:
On 1/25/21 12:29 PM, Dongsheng Yang wrote:
commit ad0d9e76(bcache: use bio op accessors) makes the bi_opf
modified by bio_set_op_attrs(). But there is a logical
problem in
fter this fix, bio to nvme will flaged as (REQ_SYNC | REQ_IDLE),
then fio for writing will get about 1000M/s bandwidth.
Fixes: ad0d9e76a412 ("bcache: use bio op accessors")
Close: EAS-60259
CC: Mike Christie
Signed-off-by: Dongsheng Yang
---
drivers/md/bcache/request.c | 2 +-
1
fter this fix, bio to nvme will flaged as (REQ_SYNC | REQ_IDLE),
then fio for writing will get about 1000M/s bandwidth.
Fixes: ad0d9e76a412 ("bcache: use bio op accessors")
CC: Mike Christie
Signed-off-by: Dongsheng Yang
---
V3-V2:
remove an unused close-line in commit message
在 2021/1/25 星期一 下午 12:53, Coly Li 写道:
On 1/25/21 12:29 PM, Dongsheng Yang wrote:
commit ad0d9e76(bcache: use bio op accessors) makes the bi_opf
modified by bio_set_op_attrs(). But there is a logical
problem in this commit:
trace_bcache_cache_insert(k
fter this fix, bio to nvme will flaged as (REQ_SYNC | REQ_IDLE),
then fio for writing will get about 1000M/s bandwidth.
Fixes: ad0d9e76a412470800c04fc4b56fc86c02d6
Signed-off-by: Dongsheng Yang
---
drivers/md/bcache/request.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
will only take effect after dirty buckets
percent is above that
Agree with that's too aggressive to reuse writeback_percent, and that's
less flexable.
Okey, let's wait for your testing result.
Thanx
Thanks,
Dongdong
On Wed, Dec 9, 2020 at 10:27 AM Dongsheng Yang
wrot
在 2020/11/3 星期二 下午 8:42, Dongdong Tao 写道:
From: dongdong tao
Current way to calculate the writeback rate only considered the
dirty sectors, this usually works fine when the fragmentation
is not high, but it will give us unreasonable small rate when
we are under a situation that very few dirty
Hi Colin,
On 03/19/2018 09:33 PM, Colin King wrote:
From: Colin Ian King
Trivial fix to spelling mistake in rdb_warn message text
Signed-off-by: Colin Ian King
---
drivers/block/rbd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/rbd.c b/drivers/block/r
Commit-ID: d740037fac7052e49450f6fa1454f1144a103b55
Gitweb: http://git.kernel.org/tip/d740037fac7052e49450f6fa1454f1144a103b55
Author: Dongsheng Yang
AuthorDate: Tue, 22 Mar 2016 16:37:08 +0800
Committer: Ingo Molnar
CommitDate: Thu, 31 Mar 2016 10:48:54 +0200
sched/cpuacct: Split
ccing: Brian and Richard
Hi Yao,
Is that really necessary? I am not sure how much benefit we can
achieve from this change.
Could you explain more?
Yang
On 03/25/2016 10:41 AM, Yaowei Bai wrote:
This series only make several funcitons return bool to improve
readability, no other funcitona
Commit-ID: 1a736b77a3f50910843d076623204ba6e5057dc1
Gitweb: http://git.kernel.org/tip/1a736b77a3f50910843d076623204ba6e5057dc1
Author: Dongsheng Yang
AuthorDate: Mon, 21 Dec 2015 19:14:42 +0800
Committer: Ingo Molnar
CommitDate: Mon, 21 Mar 2016 10:59:29 +0100
sched/cpuacct: Rename
Commit-ID: 41d93397334f3c3374810f45e7bcce9007d1a7bb
Gitweb: http://git.kernel.org/tip/41d93397334f3c3374810f45e7bcce9007d1a7bb
Author: Dongsheng Yang
AuthorDate: Wed, 13 Jan 2016 16:42:38 +0800
Committer: Ingo Molnar
CommitDate: Mon, 29 Feb 2016 09:53:05 +0100
sched/core: Remove
On 12/24/2015 12:36 AM, Eric W. Biederman wrote:
Dongsheng Yang writes:
[...]
Hi Eric,
Happy new year and sorry for the late reply.
Given the other constraints on an implementation the pid namespace looks
by far the one best suited to host such a sysctl if it is possible to
On 12/22/2015 05:52 AM, Eric W. Biederman wrote:
Dongsheng Yang writes:
On 12/20/2015 05:47 PM, Eric W. Biederman wrote:
Dongsheng Yang writes:
On 12/20/2015 10:37 AM, Al Viro wrote:
On Sun, Dec 20, 2015 at 10:14:29AM +0800, Dongsheng Yang wrote:
On 12/17/2015 07:23 PM, Dongsheng Yang
On 12/22/2015 11:12 AM, Kamezawa Hiroyuki wrote:
> On 2015/12/22 6:52, Eric W. Biederman wrote:
>> Dongsheng Yang writes:
>>
>>> On 12/20/2015 05:47 PM, Eric W. Biederman wrote:
>>>> Dongsheng Yang writes:
>>>>
>>>>> On 12/20/201
On 12/22/2015 05:33 AM, Tejun Heo wrote:
On Mon, Dec 21, 2015 at 07:14:43PM +0800, Dongsheng Yang wrote:
Sometimes, cpuacct.usage is not detialed enough to user
to see how much usage a group used. We want to know how
much time it used in user mode and how much in kernel mode.
cpuusage is
Signed-off-by: Dongsheng Yang
---
kernel/sched/cpuacct.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index dd7cbb5..9c2bbf7 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -145,13 +145,16 @@ static u6
/cgroup/cpuacct/cpuacct.usage
/sys/fs/cgroup/cpuacct/cpuacct.usage_percpu_user
/sys/fs/cgroup/cpuacct/cpuacct.usage_percpu
/sys/fs/cgroup/cpuacct/cpuacct.usage_sys
/sys/fs/cgroup/cpuacct/cpuacct.usage_percpu_sys
/sys/fs/cgroup/cpuacct/cpuacct.usage_user
Signed-off-by: Dongsheng
On 12/20/2015 05:47 PM, Eric W. Biederman wrote:
Dongsheng Yang writes:
On 12/20/2015 10:37 AM, Al Viro wrote:
On Sun, Dec 20, 2015 at 10:14:29AM +0800, Dongsheng Yang wrote:
On 12/17/2015 07:23 PM, Dongsheng Yang wrote:
Hi guys,
We are working on making core dump behaviour isolated
On 12/20/2015 10:37 AM, Al Viro wrote:
On Sun, Dec 20, 2015 at 10:14:29AM +0800, Dongsheng Yang wrote:
On 12/17/2015 07:23 PM, Dongsheng Yang wrote:
Hi guys,
We are working on making core dump behaviour isolated in
container. But the problem is, the /proc/sys/kernel/core_pattern
is a
On 12/17/2015 07:23 PM, Dongsheng Yang wrote:
Hi guys,
We are working on making core dump behaviour isolated in
container. But the problem is, the /proc/sys/kernel/core_pattern
is a kernel wide setting, not belongs to a container.
So we want to add core_pattern into mnt namespace
Hi guys,
We are working on making core dump behaviour isolated in
container. But the problem is, the /proc/sys/kernel/core_pattern
is a kernel wide setting, not belongs to a container.
So we want to add core_pattern into mnt namespace. What
do you think about it?
Yang
-
Signed-off-by: Dongsheng Yang
---
kernel/sched/cpuacct.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c
index dd7cbb5..9c2bbf7 100644
--- a/kernel/sched/cpuacct.c
+++ b/kernel/sched/cpuacct.c
@@ -145,13 +145,16 @@ static u6
/cgroup/cpuacct/cpuacct.usage
/sys/fs/cgroup/cpuacct/cpuacct.usage_percpu_user
/sys/fs/cgroup/cpuacct/cpuacct.usage_percpu
/sys/fs/cgroup/cpuacct/cpuacct.usage_sys
/sys/fs/cgroup/cpuacct/cpuacct.usage_percpu_sys
/sys/fs/cgroup/cpuacct/cpuacct.usage_user
Signed-off-by: Dongsheng
On 12/09/2015 11:29 AM, Eric W. Biederman wrote:
Dongsheng Yang writes:
On 12/09/2015 10:26 AM, Dongsheng Yang wrote:
On 10/25/2015 05:54 AM, Shayan Pooya wrote:
I noticed the following core_pattern behavior in my linux box while
running docker containers. I am not sure if it is bug, but it
On 12/09/2015 04:34 PM, Bruno Prémont wrote:
On Tue, 08 Dec 2015 21:29:13 -0600 Eric W. Biederman wrote:
Dongsheng Yang writes:
On 12/09/2015 10:26 AM, Dongsheng Yang wrote:
On 10/25/2015 05:54 AM, Shayan Pooya wrote:
I noticed the following core_pattern behavior in my linux box while
On 12/09/2015 02:32 PM, Eric W. Biederman wrote:
Dongsheng Yang writes:
On 12/09/2015 11:29 AM, Eric W. Biederman wrote:
Dongsheng Yang writes:
[...]
There has not yet been an obvious namespace in which to stick
core_pattern, and even worse exactly how to appropriate launch a process
in
On 12/09/2015 11:29 AM, Eric W. Biederman wrote:
Dongsheng Yang writes:
[...]
There has not yet been an obvious namespace in which to stick
core_pattern, and even worse exactly how to appropriate launch a process
in a container has not been figured out.
If those tricky problems can be
On 12/09/2015 10:26 AM, Dongsheng Yang wrote:
On 10/25/2015 05:54 AM, Shayan Pooya wrote:
I noticed the following core_pattern behavior in my linux box while
running docker containers. I am not sure if it is bug, but it is
inconsistent and not documented.
If the core_pattern is set on the host
On 10/25/2015 05:54 AM, Shayan Pooya wrote:
I noticed the following core_pattern behavior in my linux box while
running docker containers. I am not sure if it is bug, but it is
inconsistent and not documented.
If the core_pattern is set on the host, the containers will observe
and use the patter
On 10/28/2015 08:30 AM, Matias Bjørling wrote:
The implementation for Open-Channel SSDs is divided into media
[...]
+ lun->reserved_blocks = 2; /* for GC only */
+ lun->vlun.id = i;
+ lun->vlun.lun_id = i % dev->luns_per_chnl;
+ lun->vlun.
On 10/03/2015 01:38 AM, Brian Norris wrote:
On Fri, Oct 02, 2015 at 03:31:33PM +0530, Sudip Mukherjee wrote:
On Fri, Oct 02, 2015 at 05:39:02PM +0800, Dongsheng Yang wrote:
On 10/01/2015 12:41 AM, Sudip Mukherjee wrote:
We should prevent user to erasing mtd device with an unaligned offset
or
On 10/01/2015 12:41 AM, Sudip Mukherjee wrote:
We should prevent user to erasing mtd device with an unaligned offset
or length.
Signed-off-by: Sudip Mukherjee
---
I am not sure if I should add the Signed-off-by of
Dongsheng Yang . He is the original author
and he should get the credit for
On 09/12/2015 07:22 AM, Davidlohr Bueso wrote:
On Fri, 11 Sep 2015, Vinson Lee wrote:
Hi.
With the latest Linux 4.3-rc1, I am hitting this build error on CentOS
5.11.
HOSTCC scripts/sign-file
scripts/sign-file.c:23:25: fatal error: openssl/cms.h: No such file or
directory
#include
fwiw/r
s: %u blocks: %lu sector
size: %d\n",
.
>From 2060232d379328679b22753587d16249f01fa219 Mon Sep 17 00:00:00 2001
From: Dongsheng Yang
Date: Fri, 4 Sep 2015 08:10:13 +0900
Subject: [PATCH 2/2] lightNVM: register bm in nvm_create_target if dev->bm is
NULL
When we create target, we need to make sure dev
On 09/02/2015 06:48 PM, Matias Bjørling wrote:
+
+/* register with device with a supported BM */
+list_for_each_entry(bt, &nvm_bms, list) {
+ret = bt->register_bm(dev);
+if (ret < 0)
+goto err; /* initialization failed */
+if (ret > 0) {
+de
On 08/07/2015 10:29 PM, Matias Bjørling wrote:
These patches implement support for Open-Channel SSDs.
Applies against axboe's linux-block/for-4.3/drivers and can be found
in the lkml_v7 branch at https://github.com/OpenChannelSSD/linux
Any feedback is greatly appreciated.
Hi Matias,
A
On 08/07/2015 10:29 PM, Matias Bjørling wrote:
Open-channel SSDs are devices that share responsibilities with the host
in order to implement and maintain features that typical SSDs keep
strictly in firmware. These include (i) the Flash Translation Layer
(FTL), (ii) bad block management, and (iii)
On 08/26/2015 10:15 PM, Josh Cartwright wrote:
On Thu, Aug 20, 2015 at 10:48:38AM +0800, Dongsheng Yang wrote:
On 08/20/2015 04:35 AM, Richard Weinberger wrote:
This is a partial revert of commit d7f0b70d30ffb9bbe6b8a3e1035cf0b79965ef53
("UBIFS: Add security.* XATTR support for the
On 08/24/2015 04:03 PM, Christoph Hellwig wrote:
On Mon, Aug 24, 2015 at 11:02:42AM +0300, Artem Bityutskiy wrote:
Back when we were writing UBIFS, we did not need direct IO, so we did
not implement it. But yes, probably someone who cares could just try
implementing this feature.
So I think th
On 08/24/2015 03:17 PM, Dongsheng Yang wrote:
On 08/24/2015 03:18 PM, Artem Bityutskiy wrote:
On Thu, 2015-08-20 at 15:34 +0300, Artem Bityutskiy wrote:
On Thu, 2015-08-20 at 13:40 +0200, Richard Weinberger wrote:
Basically, we need to see what is the "common practice" here, and
On 08/24/2015 03:18 PM, Artem Bityutskiy wrote:
On Thu, 2015-08-20 at 15:34 +0300, Artem Bityutskiy wrote:
On Thu, 2015-08-20 at 13:40 +0200, Richard Weinberger wrote:
Basically, we need to see what is the "common practice" here, and
follow it. This requires a small research. What would be the
On 08/20/2015 02:42 PM, Richard Weinberger wrote:
Yang, (Sorry if I've used your last name lately)
Haha, that's fine. My friends in China all call me Dongsheng. :)
Am 20.08.2015 um 05:00 schrieb Dongsheng Yang:
On 08/20/2015 04:35 AM, Richard Weinberger wrote:
Currently UBIF
it. But I have not listed the all cons and pros of
it so far.
Artem, what's your opinion?
Yang
Cc: Dongsheng Yang
Cc: dedeki...@gmail.com
Suggested-by: Dave Chinner
Signed-off-by: Richard Weinberger
---
fs/ubifs/file.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/f
On 08/20/2015 04:35 AM, Richard Weinberger wrote:
This is a partial revert of commit d7f0b70d30ffb9bbe6b8a3e1035cf0b79965ef53
("UBIFS: Add security.* XATTR support for the UBIFS").
Hi Richard,
What about a full reverting of this commit. In ubifs, we
*can* support any namespace of xattr
On 07/08/2015 05:46 PM, Richard Weinberger wrote:
Fixes the following lockdep splat:
[1.244527] =
[1.245193] [ INFO: possible recursive locking detected ]
[1.245193] 4.2.0-rc1+ #37 Not tainted
[1.245193] -
On Tue, Aug 26, 2014 at 9:35 AM, Li Zefan wrote:
> On 2014/8/25 23:00, Dongsheng Yang wrote:
>> On Mon, Aug 25, 2014 at 10:47 PM, Tejun Heo wrote:
>>> On Mon, Aug 25, 2014 at 10:46:03PM +0800, Dongsheng Yang wrote:
>>>> My point here is that attaching and deta
On Mon, Aug 25, 2014 at 10:47 PM, Tejun Heo wrote:
> On Mon, Aug 25, 2014 at 10:46:03PM +0800, Dongsheng Yang wrote:
>> My point here is that attaching and detaching are a pair of operations.
>
> There is no detaching from a cgroup. A task is always attached to a
> cgroup whe
Hi tj,
On Mon, Aug 25, 2014 at 10:40 PM, Tejun Heo wrote:
> Hello, Dongsheng.
>
> On Mon, Aug 25, 2014 at 07:27:32PM +0800, Dongsheng Yang wrote:
>> When we create a cgroup in unified hierarchy, we have to enable
>> controllers in cgrp_dfl_root.subtree_control manually. F
Hi tj.
On Mon, Aug 25, 2014 at 10:12 PM, Tejun Heo wrote:
> On Mon, Aug 25, 2014 at 07:32:10PM +0800, Dongsheng Yang wrote:
>> Currently, the only method to detach a task from a cgroup is moving
>> it to others. It looks not natrual to me.
>
> Ummm... how is this different
Sorry for the noise, :(.
This patch is not a correct version. Please ignore it and I have sent a
v2 for it.
Thanx
On 08/25/2014 07:28 PM, Dongsheng Yang wrote:
Currently, the only method to detach a task from a cgroup is moving
it to others. It looks not natrual to me.
Inspired by
old method to allow user
echo "pid" without "+/-" to cgroup.procs as a attaching behavior.
Signed-off-by: Dongsheng Yang
---
>From v1:
*Sorry for a incorrect comment in v1.
kernel/cgroup.c | 61 +++--
1 file chang
old method to allow user
echo "pid" without "+/-" to cgroup.procs as a attaching behavior.
Signed-off-by: Dongsheng Yang
---
kernel/cgroup.c | 62 +++--
1 file changed, 60 insertions(+), 2 deletions(-)
diff --git a/kernel/cg
-by: Dongsheng Yang
---
kernel/cgroup.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 7dc8788..70996ee 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1267,12 +1267,9 @@ static int rebind_subsystems(struct cgroup_root
There is no function named cgroup_enable_task_cg_links().
Instead, the correct function name in this comment should
be cgroup_enabled_task_cg_lists().
Signed-off-by: Dongsheng Yang
---
kernel/cgroup.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/cgroup.c b
On Sun, May 25, 2014 at 9:26 PM, Manuel Schölling
wrote:
> To be future-proof and for better readability the time comparisons are
> modified to use time_before/_after() instead of plain, error-prone math.
>
> Signed-off-by: Manuel Schölling
> ---
> drivers/infiniband/hw/ipath/ipath_intr.c |4
Commit-ID: 7aa2c016db2162defff77f6f5731bff3f25e5175
Gitweb: http://git.kernel.org/tip/7aa2c016db2162defff77f6f5731bff3f25e5175
Author: Dongsheng Yang
AuthorDate: Thu, 8 May 2014 18:33:49 +0900
Committer: Ingo Molnar
CommitDate: Thu, 22 May 2014 11:16:36 +0200
sched: Consolidate open
Commit-ID: a9467fa3cd2d5bf39e7cb7d0706d29d7ef4df212
Gitweb: http://git.kernel.org/tip/a9467fa3cd2d5bf39e7cb7d0706d29d7ef4df212
Author: Dongsheng Yang
AuthorDate: Thu, 8 May 2014 18:35:15 +0900
Committer: Ingo Molnar
CommitDate: Thu, 22 May 2014 11:16:31 +0200
sched: Use clamp() and
Hi Peter, did you forget to take this patch? :-)
On Fri, Apr 4, 2014 at 8:52 PM, Peter Zijlstra wrote:
> On Thu, Apr 03, 2014 at 08:12:48PM +0800, Dongsheng Yang wrote:
>> In function set_task_cpu(), if cpu == new_cpu,
>> there is no migration happen. But current trace point
Commit-ID: 67d6259dd021006ade25d67b045ad2089b5aba96
Gitweb: http://git.kernel.org/tip/67d6259dd021006ade25d67b045ad2089b5aba96
Author: Dongsheng Yang
AuthorDate: Tue, 13 May 2014 10:38:21 +0900
Committer: Jiri Olsa
CommitDate: Fri, 16 May 2014 09:17:36 +0200
perf sched: Remove
Commit-ID: 9d372ca59bcb9339b4a34a9bf978a1fc15b68b03
Gitweb: http://git.kernel.org/tip/9d372ca59bcb9339b4a34a9bf978a1fc15b68b03
Author: Dongsheng Yang
AuthorDate: Fri, 16 May 2014 14:37:05 +0900
Committer: Jiri Olsa
CommitDate: Fri, 16 May 2014 09:17:50 +0200
perf sched: Cleanup
Commit-ID: b482e5f5c22ef95ffe7c4d86fc9719455fb24bca
Gitweb: http://git.kernel.org/tip/b482e5f5c22ef95ffe7c4d86fc9719455fb24bca
Author: Dongsheng Yang
AuthorDate: Thu, 8 May 2014 18:33:48 +0900
Committer: Thomas Gleixner
CommitDate: Mon, 19 May 2014 22:02:42 +0900
sched/prio: Add two
Commit-ID: f6156cfc0d785f8ef195d6c2f538113e041b6d44
Gitweb: http://git.kernel.org/tip/f6156cfc0d785f8ef195d6c2f538113e041b6d44
Author: Dongsheng Yang
AuthorDate: Thu, 8 May 2014 18:33:49 +0900
Committer: Thomas Gleixner
CommitDate: Mon, 19 May 2014 22:02:42 +0900
sched: Remove all
Commit-ID: 418cc9ad0cd4f67c360cdf8f4f00c3b588fb0c78
Gitweb: http://git.kernel.org/tip/418cc9ad0cd4f67c360cdf8f4f00c3b588fb0c78
Author: Dongsheng Yang
AuthorDate: Thu, 8 May 2014 18:35:15 +0900
Committer: Thomas Gleixner
CommitDate: Mon, 19 May 2014 22:02:41 +0900
sched: Use clamp
In map_switch_event(), we don't care the previous process currently,
this patch remove the infomation we get but not used.
Signed-off-by: Dongsheng Yang
---
tools/perf/builtin-sched.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/tools/perf/builtin-sched.c b/
Rather than use "if" to check and clamp values to allowed minmum or maxmum,
this patch use macros clamp() and max() to clean it up.
Signed-off-by: Dongsheng Yang
---
kernel/sched/fair.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/kernel/sched/fair.
On 05/13/2014 07:03 PM, Peter Zijlstra wrote:
On Tue, May 13, 2014 at 03:34:32PM +0900, Dongsheng Yang wrote:
On 05/13/2014 04:22 PM, Ingo Molnar wrote:
* Peter Zijlstra wrote:
trace_sched_wakeup(.success) is a dead argument and has been for ages,
Always 0, or random value?
Hi Ingo,
It
On 05/13/2014 04:22 PM, Ingo Molnar wrote:
* Peter Zijlstra wrote:
trace_sched_wakeup(.success) is a dead argument and has been for ages,
Always 0, or random value?
Hi Ingo,
It is always 1 currently.
Peter believe that .success is not useful and I pointed that perf sched
latency
is usin
Hi jiri or Arnaldo,
It seems Peter really do not like the usage of
sched_wakeup(.success), and
don't plan to support it in scheduler any more. Please consider to
append this patch
too when you take the patch from Peter. Thanx :)
On 05/13/2014 10:38 AM, Dongsheng Yang wrote:
As
As we do not use .success in sched_wakeup event any more, then
we can not guarantee that the task when wakeup event happen is
out of run queue. So the message of nr_state_machine_bugs is
not correct.
Signed-off-by: Dongsheng Yang
---
tools/perf/builtin-sched.c | 19 ---
1 file
On 05/12/2014 03:47 PM, Peter Zijlstra wrote:
On Sun, May 11, 2014 at 02:52:24PM -0400, Steven Rostedt wrote:
On Sun, 11 May 2014 18:35:31 +0200
Peter Zijlstra wrote:
I believe you may be misunderstanding Dongsheng. It has nothing to do
with the wake condition. But the "success" is basically sa
On 05/10/2014 11:29 PM, Peter Zijlstra wrote:
>
> On Tue, May 06, 2014 at 10:52:34AM +0900, Dongsheng Yang wrote:
>>
>> ttwu_do_wakeup() is called when the task's state is switched back to
>> TASK_RUNNING, whether or not the task actually scheduled out. Tracing
>
Hi steven, as you request, I resend this patch now when function task_nice()
is already in mainline. Do you want to take it?
On 05/08/2014 03:38 PM, Dongsheng Yang wrote:
Function task_nice() was reimplemented as inline function, we can use it here
to replace the open coded implementation
Hi steven, does this version look good to you?
Thanx :)
On 05/06/2014 10:52 AM, Dongsheng Yang wrote:
ttwu_do_wakeup() is called when the task's state is switched back to
TASK_RUNNING, whether or not the task actually scheduled out. Tracing
the wakeup event when the task never scheduled o
On 05/09/2014 12:26 AM, Peter Zijlstra wrote:
On Thu, May 08, 2014 at 10:51:13PM +0800, Dongsheng Yang wrote:
Just want to avoid using hardcoding of 20. If no, there is no meaning we
collect
priority related information into prio.h. And convertion between nice
value [-20,19]
and rlimit style
As there are already two inline functions in prio.h to handle the convertiion
between nice value and rlimit style value of priority, this patch remove all
open implementation of these two functions.
Signed-off-by: Dongsheng Yang
---
drivers/staging/android/binder.c | 2 +-
kernel/sched/core.c
As Kees suggested, I use clamp() function to replace the if and
else branch, making it more readable and modular.
Suggested-by: Kees Cook
Signed-off-by: Dongsheng Yang
---
kernel/sched/core.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/kernel/sched/core.c b
This patch add two inline functions named nice_to_rlimit() and rlimit_to_nice()
in prio.h.
They are handle the convertion between nice value [19,-20] and rlimit style
value [1,40].
Signed-off-by: Dongsheng Yang
---
include/linux/sched/prio.h | 16
1 file changed, 16
Function task_nice() was reimplemented as inline function, we can use it here
to replace the open coded implementation.
Signed-off-by: Dongsheng Yang
cc: Steven Rostedt
---
kernel/trace/trace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/trace.c b/kernel
On 05/07/2014 09:55 PM, Peter Zijlstra wrote:
On Wed, May 07, 2014 at 08:48:58PM +0900, Dongsheng Yang wrote:
I am not sure why we need the wrap_{max|min}() in kernel/sched/clock.c.
But I checked the implementation of max() and min() in linux/kernel.h, I think
we can reuse them here rather than
I am not sure why we need the wrap_{max|min}() in kernel/sched/clock.c.
But I checked the implementation of max() and min() in linux/kernel.h, I think
we can reuse them here rather than introduce a new function named
wrap_{max|min}().
Signed-off-by: Dongsheng Yang
---
kernel/sched/clock.c | 22
As there is a time_before64() in linux/jiffies.h we can use to
achieve our requirement here, we need not to reimplement a new
function of dl_time_before() here.
Signed-off-by: Dongsheng Yang
---
kernel/sched/cpudeadline.c | 17 ++---
kernel/sched/deadline.c| 30
As there is already a implementation in linux/jiffies.h to convert
a nsec to jiffies, so we can use it here rather than reimplement
it in sched.h.
Signed-off-by: Dongsheng Yang
---
kernel/sched/fair.c | 2 +-
kernel/sched/sched.h | 6 +-
2 files changed, 2 insertions(+), 6 deletions
From: Dongsheng
In output of perf sched map, any shortname of thread will be explained
at the first time when it appear.
Example:
*A0 228836.978985 secs A0 => perf:23032
*. A0 228836.979016 secs B0 => swapper:0
. *C0 228836.979099 secs C0 =
On 05/06/2014 03:23 PM, Ingo Molnar wrote:
* Dongsheng Yang wrote:
Example:
*A0 228836.978985 secs A0 => perf:23032
* . A0 228836.979016 secs . => swapper:0
. *B0 228836.979099 secs B0 => migration/3:22
*A0
to TASK_RUNNING.
Signed-off-by: Dongsheng Yang
---
kernel/sched/core.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 9074c6d..14b9fe4 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1420,6 +1420,7 @@ static voi
On 05/06/2014 11:06 AM, Steven Rostedt wrote:
On Tue, 6 May 2014 09:19:51 +0900
Dongsheng Yang wrote:
I wonder if we should have the event, or way to distinguish the
difference. Hmm, there's that "success" parameter in the tracepoint.
Could we possible be able to trace events wh
From: Dongsheng
In output of perf sched map, any shortname of thread will be explained
at the first time when it appear.
Example:
*A0 228836.978985 secs A0 => perf:23032
*. A0 228836.979016 secs B0 => swapper:0
. *C0 228836.979099 secs C0 =
e the tracepoint from ttwu_do_wakeup() to ttwu_activate()
where it is called only if the task is really woken up and not just
have its state changed.
Signed-off-by: Dongsheng Yang
---
kernel/sched/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/core.c b/kernel/
On 05/05/2014 11:00 PM, Steven Rostedt wrote:
On Mon, 5 May 2014 15:34:07 +0900
Dongsheng Yang wrote:
The original design of sched:sched_wakeup is to trace the event inserting
a task into run queue. It means we can know that the state of this task is
changed from "sleeping" to &q
Hi Jiri,
This patchset includes three patches for perf sched.
Please help to review. :)
Dongsheng (3):
perf tools: add missing event for perf sched record.
perf tools: Adapt the TASK_STATE_TO_CHAR_STR to new value in kernel
space.
perf tools: Clarify the output of perf sched map.
From: Dongsheng
We should record and process sched:sched_wakeup_new event in
perf sched tool, but currently, there is the process function
for it, without recording it in record subcommand.
This patch add -e sched:sched_wakeup_new to perf sched record.
Signed-off-by: Dongsheng
---
tools/perf/
From: Dongsheng
In output of perf sched map, any shortname of thread will be explained
at the first time when it appear.
Example:
*A0 228836.978985 secs A0 => perf:23032
*. A0 228836.979016 secs B0 => swapper:0
. *C0 228836.979099 secs C0 =
From: Dongsheng
Currently, TASK_STATE_TO_CHAR_STR in kernel space is already expanded to
RSDTtZXxKWP,
but it is still RSDTtZX in perf sched tool.
This patch update TASK_STATE_TO_CHAR_STR to the new value in kernel space.
Signed-off-by: Dongsheng
---
tools/perf/builtin-sched.c | 2 +-
1 file
above, this patch move the trace point of sched:sched_wakeup from
ttwu_do_wakeup() to ttwu_activate(), then when we get an event of sched_wakeup,
we can say that a task enqueued and started waiting cpu to run.
Signed-off-by: Dongsheng Yang
---
kernel/sched/core.c | 2 +-
1 file changed, 1 insertion(+), 1 del
Hi all，
Thanx for your reply, and sorry for the late.
On 04/23/2014 03:18 AM, Peter Zijlstra wrote:
On Tue, Apr 22, 2014 at 10:10:52AM -0700, bseg...@google.com wrote:
This is all expected behavior, and the somewhat less than useful trace
events are expected. A task setting p->state to TASK_RUN
On 04/16/2014 07:22 PM, Dongsheng Yang wrote:
On 04/15/2014 10:53 PM, Peter Zijlstra wrote:
On Tue, Apr 15, 2014 at 09:32:53PM +0900, Dongsheng Yang wrote:
How can you get there with ->state == RUNNING? try_to_wake_up*() bail
when !(->state & state).
Yes, try_to_wake_up() did this
Commit-ID: 8698a745d800c59cd5a576398bdeccd578ac66f1
Gitweb: http://git.kernel.org/tip/8698a745d800c59cd5a576398bdeccd578ac66f1
Author: Dongsheng Yang
AuthorDate: Tue, 11 Mar 2014 18:09:12 +0800
Committer: Ingo Molnar
CommitDate: Fri, 18 Apr 2014 12:07:24 +0200
sched, treewide: Replace
1 - 100 of 371 matches
Mail list logo
