From: "xiaofeng.yan"
function xa_store_irq() has three parameters because of removing
patameter "gfp_t gfp"
Signed-off-by: xiaofeng.yan
---
drivers/infiniband/core/cm.c| 2 +-
drivers/infiniband/hw/hns/hns_roce_qp.c | 2 +-
drivers/infiniband/hw/mlx5/srq_cmd.
From: "xiaofeng.yan"
function xa_store_irq() has a spinlock as follows:
xa_lock_irq()
-->spin_lock_irq(&(xa)->xa_lock)
GFP_KERNEL flag could cause sleep.
So change GFP_KERNEL to GFP_ATOMIC and Romve "gfp_t gfp" in function
static inline void *xa_store_irq(st
Commit-ID: 5a4fd0368517bc5b5399ef958f6d30cbff492918
Gitweb: http://git.kernel.org/tip/5a4fd0368517bc5b5399ef958f6d30cbff492918
Author: xiaofeng.yan
AuthorDate: Wed, 23 Sep 2015 14:55:59 +0800
Committer: Ingo Molnar
CommitDate: Tue, 6 Oct 2015 17:08:23 +0200
sched/core: Remove a
variable "value" in struct acpi_pnp_device_id has been changed
to "string".
Signed-off-by: xiaofeng.yan
---
drivers/acpi/acpica/nsdumpdv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/acpica/nsdumpdv.c b/drivers/acpi/acpica/nsdumpdv.c
in
TEST
--
1.9.1
--
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 at http://www.tux.org/lkml/
change tabke to take.
Signed-off-by: xiaofeng.yan
Reviewed-by: Jiang Liu
---
drivers/iommu/intel_irq_remapping.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel_irq_remapping.c
b/drivers/iommu/intel_irq_remapping.c
index 5709ae9..85676d0 100644
--- a
change tabke to take.
Signed-off-by: xiaofeng.yan
---
drivers/iommu/intel_irq_remapping.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/intel_irq_remapping.c
b/drivers/iommu/intel_irq_remapping.c
index 5709ae9..d59f82d 100644
--- a/drivers/iommu
test
--
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 at http://www.tux.org/lkml/
Commit-ID: 177ef2a6315ea7bf173653182324e1dcd08ffeaa
Gitweb: http://git.kernel.org/tip/177ef2a6315ea7bf173653182324e1dcd08ffeaa
Author: xiaofeng.yan
AuthorDate: Tue, 26 Aug 2014 03:15:41 +
Committer: Ingo Molnar
CommitDate: Sun, 7 Sep 2014 11:09:59 +0200
sched/deadline: Fix a
The overrun could happen in function start_hrtick_dl()
when a task with SCHED_DEADLINE runs in the microsecond range.
For example, a task with SCHED_DEADLINE has the following parameters
Task runtime deadline period
P1 200us 500us500us
The deadline and period from task P1 are less th
On 2014/8/12 22:52, Ingo Molnar wrote:
* xiaofeng.yan wrote:
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level. For example:
Task runtime deadline period
P1 200us 500us 500us
This case need enbale HRTICK feature by the next
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level. For example:
Task runtime deadline period
P1 200us 500us 500us
This case need enbale HRTICK feature by the next command
PC#echo "HRTICK" > /sys/kernel/debug/sched_features
PC#trace-cm
Commit-ID: 1b09d29bc00964d9032d80516f958044ac6b3805
Gitweb: http://git.kernel.org/tip/1b09d29bc00964d9032d80516f958044ac6b3805
Author: xiaofeng.yan
AuthorDate: Mon, 7 Jul 2014 05:59:04 +
Committer: Ingo Molnar
CommitDate: Wed, 16 Jul 2014 13:38:20 +0200
sched/rt: Fix
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level. For example:
Task runtime deadline period
P1 200us 500us 500us
This case need enbale HRTICK feature by the next command
PC#echo "HRTICK" > /sys/kernel/debug/sched_features
PC#trace-cm
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level. For example:
Task runtime deadline period
P1 200us 500us 500us
This case need enbale HRTICK feature by the next command
PC#echo "HRTICK" > /sys/kernel/debug/sched_features
PC#trace-cm
Move this piece of code with the limit of the least time slice
from hrtick_start_fair() to hrtick_start() because
EDF schedule class also need this function in start_hrtick_dl().
EDF tasks with the runtime of microsecond level will lead to the wrong
precision because system can't control the end o
On 2014/7/8 20:52, Peter Zijlstra wrote:
On Tue, Jul 08, 2014 at 07:50:22PM +0800, xiaofeng.yan wrote:
I have tested this solution, It can work very well with deadline schedule
class.
Great, please send it as a proper patch and I might just press 'A' ;-)
Ok, I will send it late
On 2014/7/8 19:23, xiaofeng.yan wrote:
On 2014/7/8 17:33, Peter Zijlstra wrote:
On Tue, Jul 08, 2014 at 08:53:27AM +, xiaofeng.yan wrote:
static void start_hrtick_dl(struct rq *rq, struct task_struct *p)
{
-s64 delta = p->dl.dl_runtime - p->dl.runtime;
-
-if (delta &
On 2014/7/8 17:33, Peter Zijlstra wrote:
On Tue, Jul 08, 2014 at 08:53:27AM +, xiaofeng.yan wrote:
static void start_hrtick_dl(struct rq *rq, struct task_struct *p)
{
- s64 delta = p->dl.dl_runtime - p->dl.runtime;
-
- if (delta > 1)
- hrtick_st
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level. For example:
Task runtime deadline period
P1 200us 500us 500us
This case need enbale HRTICK feature by the next command
PC#echo "HRTICK" > /sys/kernel/debug/sched_features
PC#trace-cm
On 2014/7/8 16:53, xiaofeng.yan wrote:
Sorry, I send a old patch and send a new one later.
Thanks
Yan
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level. For example:
Task runtime deadline period
P1 200us 500us 500us
This case
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level. For example:
Task runtime deadline period
P1 200us 500us 500us
This case need enbale HRTICK feature by the next command
PC#echo "HRTICK" > /sys/kernel/debug/sched_features
PC#trace-cm
On 2014/7/8 15:49, Peter Zijlstra wrote:
On Tue, Jul 08, 2014 at 10:51:02AM +0800, xiaofeng.yan wrote:
On 2014/7/8 10:40, Li Zefan wrote:
On 2014/7/8 9:10, xiaofeng.yan wrote:
On 2014/7/7 16:41, Peter Zijlstra wrote:
On Fri, Jul 04, 2014 at 12:02:21PM +, xiaofeng.yan wrote:
It could be
On 2014/7/8 10:40, Li Zefan wrote:
On 2014/7/8 9:10, xiaofeng.yan wrote:
On 2014/7/7 16:41, Peter Zijlstra wrote:
On Fri, Jul 04, 2014 at 12:02:21PM +, xiaofeng.yan wrote:
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level. For
On 2014/7/7 16:41, Peter Zijlstra wrote:
On Fri, Jul 04, 2014 at 12:02:21PM +, xiaofeng.yan wrote:
It could be wrong for the precision of runtime and deadline
when the precision is within microsecond level. For example:
Task runtime deadline period
P1 200us 500us 500us
This case
Signed-off-by: xiaofeng.yan
---
kernel/sched/deadline.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index fc4f98b1..6541565 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -306,7 +306,7 @@ static
hen runtime is less than
10us.
So the process will continue to run until tick-period coming.
For fixing this problem, Let delta is equal to 10us when it is less than 10us.
So the hrtimer will start up to control the end of process.
Signed-off-by: xiaofeng.yan
---
kernel/sched/deadline.c |
On 2014/6/19 17:13, Luca Abeni wrote:
On 06/18/2014 09:01 AM, xiaofeng.yan wrote:
[...]
I also had an implementation of the GRUB algorithm (based on a
modification
of my old CBS scheduler for Linux), but the computational
complexity of the
algorithm was too high. That's why I never propos
On 2014/6/17 16:01, Luca Abeni wrote:
Hi,
On 06/17/2014 04:43 AM, xiaofeng.yan wrote:
[...]
The basic ideas are (warning! This is an over-simplification of the
algorithm! :)
- You assign runtime and period to each SCHED_DEADLINE task as usual
- Each task is guaranteed to receive its runtime
On 2014/5/21 20:45, Luca Abeni wrote:
Hi,
first of all, sorry for the ultra-delayed reply: I've been busy,
and I did not notice this email... Anyway, some comments are below
On 05/16/2014 09:11 AM, Henrik Austad wrote:
[...]
This can also be implemented in user-space (without modifying the
sch
Commit-ID: 4027d080854d1be96ef134a1c3024d5276114db6
Gitweb: http://git.kernel.org/tip/4027d080854d1be96ef134a1c3024d5276114db6
Author: xiaofeng.yan
AuthorDate: Fri, 9 May 2014 03:21:27 +
Committer: Ingo Molnar
CommitDate: Thu, 22 May 2014 11:16:37 +0200
sched/rt: Fix 's
Commit-ID: 6e9a8b9d6a9257bc124a1609f25597064ef9c167
Gitweb: http://git.kernel.org/tip/6e9a8b9d6a9257bc124a1609f25597064ef9c167
Author: xiaofeng.yan
AuthorDate: Mon, 12 May 2014 07:41:17 +
Committer: Thomas Gleixner
CommitDate: Mon, 19 May 2014 22:02:42 +0900
sched/rt: Fix a
Commit-ID: c07a16f784dfb8083c3b0157fbef18cb1292b9fc
Gitweb: http://git.kernel.org/tip/c07a16f784dfb8083c3b0157fbef18cb1292b9fc
Author: xiaofeng.yan
AuthorDate: Fri, 9 May 2014 03:21:27 +
Committer: Thomas Gleixner
CommitDate: Mon, 19 May 2014 22:02:42 +0900
sched/rt: Fix a comment
EDF use sched_setattr() instead of sched_setscheduler().
Signed-off-by: xiaofeng.yan
---
kernel/sched/deadline.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index b080957..558e41a 100644
--- a/kernel/sched/deadline.c
ff-by: xiaofeng.yan
---
include/linux/sched.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 25f54c7..ed64468 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1123,8 +1123,8 @@ struct sched_dl_e
On 2014/5/8 19:04, Peter Zijlstra wrote:
On Thu, May 08, 2014 at 10:31:20AM +, xiaofeng.yan wrote:
Change sched_setscheduler2() to sched_setscheduler() in the comments.
There isn't function sched_setscheduler2() in the main line.
The previous EDF version defines this function
before
) now.
Signed-off-by: xiaofeng.yan
---
include/linux/sched.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 25f54c7..fe263e7 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1123,8 +1123,8 @@ s
37 matches
Mail list logo