2016-09-22 18:08 GMT+08:00 Peter Zijlstra <pet...@infradead.org>:
> On Thu, Sep 22, 2016 at 05:50:53PM +0800, Zhu Yanhai wrote:
>> From: Zhu Yanhai <gaoyang@taobao.com>
>>
>> I can't see why the check was removed by commit b32e86b4. Since it was not
>> r
2016-09-22 18:08 GMT+08:00 Peter Zijlstra :
> On Thu, Sep 22, 2016 at 05:50:53PM +0800, Zhu Yanhai wrote:
>> From: Zhu Yanhai
>>
>> I can't see why the check was removed by commit b32e86b4. Since it was not
>> relevant to the subject of the commit, I gue
From: Zhu Yanhai <gaoyang@taobao.com>
I can't see why the check was removed by commit b32e86b4. Since it was not
relevant to the subject of the commit, I guess it was just a plain typo.
Signed-off-by: Zhu Yanhai <gaoyang@taobao.com>
---
kernel/sched/debug.c | 2 +-
1 fil
From: Zhu Yanhai
I can't see why the check was removed by commit b32e86b4. Since it was not
relevant to the subject of the commit, I guess it was just a plain typo.
Signed-off-by: Zhu Yanhai
---
kernel/sched/debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel
-clts() around the enabling/disabling
interrupts is a really ugly hack.
Maintainers, any thoughts?
--
Thanks,
Zhu Yanhai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kerne
interrupts is a really ugly hack.
Maintainers, any thoughts?
--
Thanks,
Zhu Yanhai
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
ot;movw $0, (%0)",
X86_FEATURE_UNFAIR_SPINLOCK)
:
: "Q" (>slock)
: "memory", "cc");
}
While both UNLOCK_LOCK_PREFIX and UNLOCK_LOCK_ALT_PREFIX are empty
strings. So how such a function keeps the memory operations issued
before it completed?
--
Thanks,
Zhu Y
),
X86_FEATURE_UNFAIR_SPINLOCK)
:
: Q (lock-slock)
: memory, cc);
}
While both UNLOCK_LOCK_PREFIX and UNLOCK_LOCK_ALT_PREFIX are empty
strings. So how such a function keeps the memory operations issued
before it completed?
--
Thanks,
Zhu Yanhai
--
To unsubscribe from this list: send the line
Commit-ID: a59f4e079d19464eebb9b06513a1d4f55fdae5ba
Gitweb: http://git.kernel.org/tip/a59f4e079d19464eebb9b06513a1d4f55fdae5ba
Author: Zhu Yanhai
AuthorDate: Tue, 8 Jan 2013 12:56:52 +0800
Committer: Ingo Molnar
CommitDate: Thu, 24 Jan 2013 14:41:00 +0100
sched: Fix the broken
Commit-ID: a59f4e079d19464eebb9b06513a1d4f55fdae5ba
Gitweb: http://git.kernel.org/tip/a59f4e079d19464eebb9b06513a1d4f55fdae5ba
Author: Zhu Yanhai gaoyang@taobao.com
AuthorDate: Tue, 8 Jan 2013 12:56:52 +0800
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Thu, 24 Jan 2013 14:41
. Besides the change seems to be irrelevant to the commit
msg, which was to return a 0 timeslice for tasks that are on an idle runqueue.
So I believe that was just a plain typo.
Signed-off-by: Zhu Yanhai
---
kernel/sched/fair.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
. Besides the change seems to be irrelevant to the commit
msg, which was to return a 0 timeslice for tasks that are on an idle runqueue.
So I believe that was just a plain typo.
Signed-off-by: Zhu Yanhai gaoyang@taobao.com
---
kernel/sched/fair.c | 2 +-
1 file changed, 1 insertion(+), 1
12 matches
Mail list logo