[PATCH 2/2] infiniband: Modify the reference to xa_store_irq() because the parameter of this function has changed

[xiaofeng.yan]

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.c| 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
index 5740d1ba3568..afcb5711270b 100644
--- a/drivers/infiniband/core/cm.c
+++ b/drivers/infiniband/core/cm.c
@@ -879,7 +879,7 @@ static struct cm_id_private *cm_alloc_id_priv(struct 
ib_device *device,
 static void cm_finalize_id(struct cm_id_private *cm_id_priv)
 {
xa_store_irq(&cm.local_id_table, cm_local_id(cm_id_priv->id.local_id),
-cm_id_priv, GFP_KERNEL);
+cm_id_priv);
 }
 
 struct ib_cm_id *ib_create_cm_id(struct ib_device *device,
diff --git a/drivers/infiniband/hw/hns/hns_roce_qp.c 
b/drivers/infiniband/hw/hns/hns_roce_qp.c
index 6c081dd985fc..1876a51f9e08 100644
--- a/drivers/infiniband/hw/hns/hns_roce_qp.c
+++ b/drivers/infiniband/hw/hns/hns_roce_qp.c
@@ -237,7 +237,7 @@ static int hns_roce_qp_store(struct hns_roce_dev *hr_dev,
if (!hr_qp->qpn)
return -EINVAL;
 
-   ret = xa_err(xa_store_irq(xa, hr_qp->qpn, hr_qp, GFP_KERNEL));
+   ret = xa_err(xa_store_irq(xa, hr_qp->qpn, hr_qp));
if (ret)
dev_err(hr_dev->dev, "Failed to xa store for QPC\n");
else
diff --git a/drivers/infiniband/hw/mlx5/srq_cmd.c 
b/drivers/infiniband/hw/mlx5/srq_cmd.c
index db889ec3fd48..f277e264ceab 100644
--- a/drivers/infiniband/hw/mlx5/srq_cmd.c
+++ b/drivers/infiniband/hw/mlx5/srq_cmd.c
@@ -578,7 +578,7 @@ int mlx5_cmd_create_srq(struct mlx5_ib_dev *dev, struct 
mlx5_core_srq *srq,
refcount_set(&srq->common.refcount, 1);
init_completion(&srq->common.free);
 
-   err = xa_err(xa_store_irq(&table->array, srq->srqn, srq, GFP_KERNEL));
+   err = xa_err(xa_store_irq(&table->array, srq->srqn, srq));
if (err)
goto err_destroy_srq_split;
 
-- 
2.17.1

[PATCH 1/2] [xarry]:Fixed an issue with memory allocated using the GFP_KERNEL flag in spinlocks

[xiaofeng.yan]

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(struct xarray *xa, unsigned long index,
void *entry, gfp_t gfp)

Signed-off-by: xiaofeng.yan 
---
 include/linux/xarray.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/include/linux/xarray.h b/include/linux/xarray.h
index 92c0160b3352..aeaf97d5642f 100644
--- a/include/linux/xarray.h
+++ b/include/linux/xarray.h
@@ -595,7 +595,6 @@ static inline void *xa_store_bh(struct xarray *xa, unsigned 
long index,
  * @xa: XArray.
  * @index: Index into array.
  * @entry: New entry.
- * @gfp: Memory allocation flags.
  *
  * This function is like calling xa_store() except it disables interrupts
  * while holding the array lock.
@@ -605,12 +604,12 @@ static inline void *xa_store_bh(struct xarray *xa, 
unsigned long index,
  * Return: The old entry at this index or xa_err() if an error happened.
  */
 static inline void *xa_store_irq(struct xarray *xa, unsigned long index,
-   void *entry, gfp_t gfp)
+   void *entry)
 {
void *curr;
 
xa_lock_irq(xa);
-   curr = __xa_store(xa, index, entry, gfp);
+   curr = __xa_store(xa, index, entry, GFP_ATOMIC);
xa_unlock_irq(xa);
 
return curr;
-- 
2.17.1

[tip:sched/core] sched/core: Remove a parameter in the migrate_task_rq() function

[tip-bot for xiaofeng.yan]

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 parameter in the migrate_task_rq() function

The parameter "int next_cpu" in the following function is unused:

  migrate_task_rq(struct task_struct *p, int next_cpu)

Remove it.

Signed-off-by: xiaofeng.yan 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Linus Torvalds 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-kernel@vger.kernel.org
Link: 
http://lkml.kernel.org/r/1442991360-31945-1-git-send-email-yanxiaof...@inspur.com
Signed-off-by: Ingo Molnar 
---
 kernel/sched/core.c  | 2 +-
 kernel/sched/fair.c  | 2 +-
 kernel/sched/sched.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index a395db1..1764a0f 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1294,7 +1294,7 @@ void set_task_cpu(struct task_struct *p, unsigned int 
new_cpu)
 
if (task_cpu(p) != new_cpu) {
if (p->sched_class->migrate_task_rq)
-   p->sched_class->migrate_task_rq(p, new_cpu);
+   p->sched_class->migrate_task_rq(p);
p->se.nr_migrations++;
perf_event_task_migrate(p);
}
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 3bdc3da..700eb54 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5009,7 +5009,7 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, 
int sd_flag, int wake_f
  * previous cpu.  However, the caller only guarantees p->pi_lock is held; no
  * other assumptions, including the state of rq->lock, should be made.
  */
-static void migrate_task_rq_fair(struct task_struct *p, int next_cpu)
+static void migrate_task_rq_fair(struct task_struct *p)
 {
/*
 * We are supposed to update the task to "current" time, then its up to 
date
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index e08cc4c..efd3bfc 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1190,7 +1190,7 @@ struct sched_class {
 
 #ifdef CONFIG_SMP
int  (*select_task_rq)(struct task_struct *p, int task_cpu, int 
sd_flag, int flags);
-   void (*migrate_task_rq)(struct task_struct *p, int next_cpu);
+   void (*migrate_task_rq)(struct task_struct *p);
 
void (*task_waking) (struct task_struct *task);
void (*task_woken) (struct rq *this_rq, struct task_struct *task);
--
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/

[PATCH] ACPI, Repair of outdated variable

[xiaofeng.yan]

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
index 7dc367e..1af1af7 100644
--- a/drivers/acpi/acpica/nsdumpdv.c
+++ b/drivers/acpi/acpica/nsdumpdv.c
@@ -89,7 +89,7 @@ acpi_ns_dump_one_device(acpi_handle obj_handle,
 
ACPI_DEBUG_PRINT_RAW((ACPI_DB_TABLES,
  "HID: %s, ADR: %8.8X%8.8X, Status: 
%X\n",
- info->hardware_id.value,
+ info->hardware_id.string,
  ACPI_FORMAT_UINT64(info->address),
  info->current_status));
ACPI_FREE(info);
-- 
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/

[PATCH v2] *** TEST ***

[xiaofeng.yan]

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/

[PATCH v2] Intel_irq_remapping: fix a comment error

[xiaofeng.yan]

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/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -46,7 +46,7 @@ static struct hpet_scope ir_hpet[MAX_HPET_TBS];
  * ->iommu->register_lock
  * Note:
  * intel_irq_remap_ops.{supported,prepare,enable,disable,reenable} are called
- * in single-threaded environment with interrupt disabled, so no need to tabke
+ * in single-threaded environment with interrupt disabled, so no need to take
  * the dmar_global_lock.
  */
 static DEFINE_RAW_SPINLOCK(irq_2_ir_lock);
-- 
1.9.1


___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH] intel_irq_remapping: fix a comment error

[xiaofeng.yan]

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/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -46,7 +46,7 @@ static struct hpet_scope ir_hpet[MAX_HPET_TBS];
  * ->iommu->register_lock
  * Note:
  * intel_irq_remap_ops.{supported,prepare,enable,disable,reenable} are called
- * in single-threaded environment with interrupt disabled, so no need to tabke
+ * in single-threaded environment with interrupt disabled, so no need to take
  * the dmar_global_lock.
  */
 static DEFINE_RAW_SPINLOCK(irq_2_ir_lock);
@@ -185,6 +185,7 @@ static int modify_irte(int irq, struct irte *irte_modified)
return -1;
 
raw_spin_lock_irqsave(&irq_2_ir_lock, flags);
+   while(1):
 
iommu = irq_iommu->iommu;
 
-- 
1.9.1


___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v2] Intel_irq_remapping: fix a comment error

[xiaofeng.yan]

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/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -46,7 +46,7 @@ static struct hpet_scope ir_hpet[MAX_HPET_TBS];
  * ->iommu->register_lock
  * Note:
  * intel_irq_remap_ops.{supported,prepare,enable,disable,reenable} are called
- * in single-threaded environment with interrupt disabled, so no need to tabke
+ * in single-threaded environment with interrupt disabled, so no need to take
  * the dmar_global_lock.
  */
 static DEFINE_RAW_SPINLOCK(irq_2_ir_lock);
-- 
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/

[PATCH] intel_irq_remapping: fix a comment error

[xiaofeng.yan]

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/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -46,7 +46,7 @@ static struct hpet_scope ir_hpet[MAX_HPET_TBS];
  * ->iommu->register_lock
  * Note:
  * intel_irq_remap_ops.{supported,prepare,enable,disable,reenable} are called
- * in single-threaded environment with interrupt disabled, so no need to tabke
+ * in single-threaded environment with interrupt disabled, so no need to take
  * the dmar_global_lock.
  */
 static DEFINE_RAW_SPINLOCK(irq_2_ir_lock);
@@ -185,6 +185,7 @@ static int modify_irte(int irq, struct irte *irte_modified)
return -1;
 
raw_spin_lock_irqsave(&irq_2_ir_lock, flags);
+   while(1):
 
iommu = irq_iommu->iommu;
 
-- 
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/

[PATCH] ARM: sched_clock: Load cycle count after epoch stabilizes

[xiaofeng.yan]

From: Stephen Boyd 

There is a small race between when the cycle count is read from
the hardware and when the epoch stabilizes. Consider this
scenario:

 CPU0   CPU1
    
 cyc = read_sched_clock()
 cyc_to_sched_clock()
 update_sched_clock()
  ...
  cd.epoch_cyc = cyc;
  epoch_cyc = cd.epoch_cyc;
  ...
  epoch_ns + cyc_to_ns((cyc - epoch_cyc)

The cyc on cpu0 was read before the epoch changed. But we
calculate the nanoseconds based on the new epoch by subtracting
the new epoch from the old cycle count. Since epoch is most likely
larger than the old cycle count we calculate a large number that
will be converted to nanoseconds and added to epoch_ns, causing
time to jump forward too much.

Fix this problem by reading the hardware after the epoch has
stabilized.

Cc: Russell King 
Signed-off-by: Stephen Boyd 
Signed-off-by: John Stultz 
[xiaofeng.yan: Backported to 3.10: reomve duplicated code after cherry-pick]
Signed-off-by: xiaofeng.yan 
---
 arch/arm/kernel/sched_clock.c |   13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
index e8edcaa..a57cc5d 100644
--- a/arch/arm/kernel/sched_clock.c
+++ b/arch/arm/kernel/sched_clock.c
@@ -51,10 +51,11 @@ static inline u64 notrace cyc_to_ns(u64 cyc, u32 mult, u32 
shift)
return (cyc * mult) >> shift;
 }
 
-static unsigned long long notrace cyc_to_sched_clock(u32 cyc, u32 mask)
+static unsigned long long notrace sched_clock_32(void)
 {
u64 epoch_ns;
u32 epoch_cyc;
+   u32 cyc;
 
if (cd.suspended)
return cd.epoch_ns;
@@ -73,7 +74,9 @@ static unsigned long long notrace cyc_to_sched_clock(u32 cyc, 
u32 mask)
smp_rmb();
} while (epoch_cyc != cd.epoch_cyc_copy);
 
-   return epoch_ns + cyc_to_ns((cyc - epoch_cyc) & mask, cd.mult, 
cd.shift);
+   cyc = read_sched_clock();
+   cyc = (cyc - epoch_cyc) & sched_clock_mask;
+   return epoch_ns + cyc_to_ns(cyc, cd.mult, cd.shift);
 }
 
 /*
@@ -165,12 +168,6 @@ void __init setup_sched_clock(u32 (*read)(void), int bits, 
unsigned long rate)
pr_debug("Registered %pF as sched_clock source\n", read);
 }
 
-static unsigned long long notrace sched_clock_32(void)
-{
-   u32 cyc = read_sched_clock();
-   return cyc_to_sched_clock(cyc, sched_clock_mask);
-}
-
 unsigned long long __read_mostly (*sched_clock_func)(void) = sched_clock_32;
 
 unsigned long long notrace sched_clock(void)
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3][request for stable inclusion][3.10.x]:ARM:sched_clock: Load cycle count after epoch stabilizes

[xiaofeng.yan]

commit 336ae1180df5f69b9e0fb6561bec01c5f64361cf
ARM: sched_clock: Load cycle count after epoch stabilizes

This looks applicable to stable-3.10, which load cycle count after epoch 
stabilizes,
The function was moved from arch/arm/kernel/sched_clock.c to 
kernel/time/sched_clock.c because of upgrading version.
The commit id is 336ae1180df5f69b9e0fb6561bec01c5f64361cf in 3.18.
I designed a test case for recurring this bug as follows:

 CPU0 CPU1
  
 g_counter = 1;
 ...
 cyc = read_sched_clock()
 cyc_to_sched_clock()
 update_sched_clock()
  ...
  cd.epoch_cyc = cyc;
  g_counter = 2;
  epoch_cyc = cd.epoch_cyc;
  if(g_counter == 2)
printk("error!\n");
   g_counter = 1;
  ...
  epoch_ns + cyc_to_ns((cyc - epoch_cyc)

The bug will be proven to exist if the strings "error!" happen on screen.

I find that "error!" happen firstly on screen in thirty hours.

The patch for test is as follows:
--- a/sched_clock.c2014-11-25 08:24:15.0 +
+++ b/sched_clock.c   2014-12-01 08:46:32.0 +
@@ -15,7 +15,7 @@
 #include 

 #include 
-
+unsigned int g_counter = 0;
 struct clock_data {
u64 epoch_ns;
u32 epoch_cyc;
@@ -68,11 +68,14 @@
 */
do {
epoch_cyc = cd.epoch_cyc;
+   if(g_counter == 2)
+   printk("error!\n");
+   g_counter = 1;
smp_rmb();
epoch_ns = cd.epoch_ns;
smp_rmb();
} while (epoch_cyc != cd.epoch_cyc_copy);
-
+   
return epoch_ns + cyc_to_ns((cyc - epoch_cyc) & mask, cd.mult, 
cd.shift);
 }

@@ -99,6 +102,7 @@
cd.epoch_ns = ns;
smp_wmb();
cd.epoch_cyc = cyc;
+   g_counter = 2;
raw_local_irq_restore(flags);
 }

@@ -168,6 +172,7 @@
 static unsigned long long notrace sched_clock_32(void)
 {
u32 cyc = read_sched_clock();
+   g_counter = 1;
return cyc_to_sched_clock(cyc, sched_clock_mask);
 }

Stephen Boyd (1):
  ARM: sched_clock: Load cycle count after epoch stabilizes

 arch/arm/kernel/sched_clock.c |   13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2][request for stable inclusion][3.10.x]:ARM:sched_clock: Load cycle count after epoch stabilizes

[xiaofeng.yan]

commit 336ae1180df5f69b9e0fb6561bec01c5f64361cf
ARM: sched_clock: Load cycle count after epoch stabilizes

This looks applicable to stable-3.10, which load cycle count after epoch 
stabilizes,
The function was moved from arch/arm/kernel/sched_clock.c to 
kernel/time/sched_clock.c because of upgrading version.
The commit id is 336ae1180df5f69b9e0fb6561bec01c5f64361cf in 3.18.
I designed a test case for recurring this bug as follows:

 CPU0 CPU1
  
 g_counter = 1;
 ...
 cyc = read_sched_clock()
 cyc_to_sched_clock()
 update_sched_clock()
  ...
  cd.epoch_cyc = cyc;
  g_counter = 2;
  epoch_cyc = cd.epoch_cyc;
  if(g_counter == 2)
printk("error!\n");
   g_counter = 1;
  ...
  epoch_ns + cyc_to_ns((cyc - epoch_cyc)

The bug will be proven to exist if the strings "error!" happen on screen.

I find that "error!" happen firstly on screen in thirty hours.

The patch for test is as follows:
--- a/sched_clock.c2014-11-25 08:24:15.0 +
+++ b/sched_clock.c   2014-12-01 08:46:32.0 +
@@ -15,7 +15,7 @@
 #include 

 #include 
-
+unsigned int g_counter = 0;
 struct clock_data {
u64 epoch_ns;
u32 epoch_cyc;
@@ -68,11 +68,14 @@
 */
do {
epoch_cyc = cd.epoch_cyc;
+   if(g_counter == 2)
+   printk("error!\n");
+   g_counter = 1;
smp_rmb();
epoch_ns = cd.epoch_ns;
smp_rmb();
} while (epoch_cyc != cd.epoch_cyc_copy);
-
+   
return epoch_ns + cyc_to_ns((cyc - epoch_cyc) & mask, cd.mult, 
cd.shift);
 }

@@ -99,6 +102,7 @@
cd.epoch_ns = ns;
smp_wmb();
cd.epoch_cyc = cyc;
+   g_counter = 2;
raw_local_irq_restore(flags);
 }

@@ -168,6 +172,7 @@
 static unsigned long long notrace sched_clock_32(void)
 {
u32 cyc = read_sched_clock();
+   g_counter = 1;
return cyc_to_sched_clock(cyc, sched_clock_mask);
 }

Stephen Boyd (1):
  ARM: sched_clock: Load cycle count after epoch stabilizes

 arch/arm/kernel/sched_clock.c |   13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: sched_clock: Load cycle count after epoch stabilizes

[xiaofeng.yan]

There is a small race between when the cycle count is read from
the hardware and when the epoch stabilizes. Consider this scenario:
CPU0   CPU1
   
cyc = read_sched_clock()
cyc_to_sched_clock()
 update_sched_clock()
  ...
 cd.epoch_cyc = cyc;
epoch_cyc = cd.epoch_cyc;
  ...
epoch_ns + cyc_to_ns((cyc - epoch_cyc)

The cyc on cpu0 was read before the epoch changed. But we
calculate the nanoseconds based on the new epoch by subtracting
the new epoch from the old cycle count. Since epoch is most likely
larger than the old cycle count we calculate a large number that
will be converted to nanoseconds and added to epoch_ns, causing
time to jump forward too much.

Fix this problem by reading the hardware after the epoch has stabilized.

Cc: Russell King 
Signed-off-by: Stephen Boyd 
Signed-off-by: John Stultz 
Tested-by: xiaofeng.yan 
---
Found this while reading through the code. I haven't actually
seen it in practice but I think it's real.
---
 arch/arm/kernel/sched_clock.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
index e8edcaa..a57cc5d 100644
--- a/arch/arm/kernel/sched_clock.c
+++ b/arch/arm/kernel/sched_clock.c
@@ -51,10 +51,11 @@ static inline u64 notrace cyc_to_ns(u64 cyc, u32 mult, u32 
shift)
return (cyc * mult) >> shift;
 }
 
-static unsigned long long notrace cyc_to_sched_clock(u32 cyc, u32 mask)
+static unsigned long long notrace sched_clock_32(void)
 {
u64 epoch_ns;
u32 epoch_cyc;
+   u32 cyc;
 
if (cd.suspended)
return cd.epoch_ns;
@@ -73,7 +74,9 @@ static unsigned long long notrace cyc_to_sched_clock(u32 cyc, 
u32 mask)
smp_rmb();
} while (epoch_cyc != cd.epoch_cyc_copy);
 
-   return epoch_ns + cyc_to_ns((cyc - epoch_cyc) & mask, cd.mult, 
cd.shift);
+   cyc = read_sched_clock();
+   cyc = (cyc - epoch_cyc) & sched_clock_mask;
+   return epoch_ns + cyc_to_ns(cyc, cd.mult, cd.shift);
 }
 
 /*
@@ -165,12 +168,6 @@ void __init setup_sched_clock(u32 (*read)(void), int bits, 
unsigned long rate)
pr_debug("Registered %pF as sched_clock source\n", read);
 }
 
-static unsigned long long notrace sched_clock_32(void)
-{
-   u32 cyc = read_sched_clock();
-   return cyc_to_sched_clock(cyc, sched_clock_mask);
-}
-
 unsigned long long __read_mostly (*sched_clock_func)(void) = sched_clock_32;
 
 unsigned long long notrace sched_clock(void)
-- 
1.8.3.4

--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: sched_clock: Load cycle count after epoch stabilizes

[xiaofeng.yan]

On 2014/12/6 17:57, Russell King - ARM Linux wrote:

On Fri, Dec 05, 2014 at 02:17:19PM -0800, Greg KH wrote:

On Fri, Nov 28, 2014 at 02:18:58AM +, xiaofeng.yan wrote:

From: Stephen Boyd 

There is a small race between when the cycle count is read from
the hardware and when the epoch stabilizes. Consider this
scenario:

  CPU0   CPU1
     
  cyc = read_sched_clock()
  cyc_to_sched_clock()
  update_sched_clock()
   ...
   cd.epoch_cyc = cyc;
   epoch_cyc = cd.epoch_cyc;
   ...
   epoch_ns + cyc_to_ns((cyc - epoch_cyc)

The cyc on cpu0 was read before the epoch changed. But we
calculate the nanoseconds based on the new epoch by subtracting
the new epoch from the old cycle count. Since epoch is most likely
larger than the old cycle count we calculate a large number that
will be converted to nanoseconds and added to epoch_ns, causing
time to jump forward too much.

Fix this problem by reading the hardware after the epoch has
stabilized.

Cc: Russell King 
Signed-off-by: Stephen Boyd 
Signed-off-by: John Stultz 
---
  kernel/time/sched_clock.c |   19 ---

This file isn't even in the 3.10-stable kernel tree, so there is no way
you have tested this patch :(

arch/arm/kernel/sched_clock.c
Sorry for my fault. I have submitted my patch and had a test for this 
bug, Please check it with
 title "[PATCH][request for stable inclusion][3.10.x]: ARM: 
sched_clock: Load cycle count after epoch stabilizes"


Thanks
Yan


--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: sched_clock: Load cycle count after epoch stabilizes

[xiaofeng.yan]

There is a small race between when the cycle count is read from
the hardware and when the epoch stabilizes. Consider this scenario:
CPU0   CPU1
   
cyc = read_sched_clock()
cyc_to_sched_clock()
 update_sched_clock()
  ...
 cd.epoch_cyc = cyc;
epoch_cyc = cd.epoch_cyc;
  ...
epoch_ns + cyc_to_ns((cyc - epoch_cyc)

The cyc on cpu0 was read before the epoch changed. But we
calculate the nanoseconds based on the new epoch by subtracting
the new epoch from the old cycle count. Since epoch is most likely
larger than the old cycle count we calculate a large number that
will be converted to nanoseconds and added to epoch_ns, causing
time to jump forward too much.

Fix this problem by reading the hardware after the epoch has stabilized.

Cc: Russell King 
Signed-off-by: Stephen Boyd 
Signed-off-by: John Stultz 
Tested-by: xiaofeng.yan 
---
Found this while reading through the code. I haven't actually
seen it in practice but I think it's real.
---
 arch/arm/kernel/sched_clock.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/arch/arm/kernel/sched_clock.c b/arch/arm/kernel/sched_clock.c
index e8edcaa..a57cc5d 100644
--- a/arch/arm/kernel/sched_clock.c
+++ b/arch/arm/kernel/sched_clock.c
@@ -51,10 +51,11 @@ static inline u64 notrace cyc_to_ns(u64 cyc, u32 mult, u32 
shift)
return (cyc * mult) >> shift;
 }
 
-static unsigned long long notrace cyc_to_sched_clock(u32 cyc, u32 mask)
+static unsigned long long notrace sched_clock_32(void)
 {
u64 epoch_ns;
u32 epoch_cyc;
+   u32 cyc;
 
if (cd.suspended)
return cd.epoch_ns;
@@ -73,7 +74,9 @@ static unsigned long long notrace cyc_to_sched_clock(u32 cyc, 
u32 mask)
smp_rmb();
} while (epoch_cyc != cd.epoch_cyc_copy);
 
-   return epoch_ns + cyc_to_ns((cyc - epoch_cyc) & mask, cd.mult, 
cd.shift);
+   cyc = read_sched_clock();
+   cyc = (cyc - epoch_cyc) & sched_clock_mask;
+   return epoch_ns + cyc_to_ns(cyc, cd.mult, cd.shift);
 }
 
 /*
@@ -165,12 +168,6 @@ void __init setup_sched_clock(u32 (*read)(void), int bits, 
unsigned long rate)
pr_debug("Registered %pF as sched_clock source\n", read);
 }
 
-static unsigned long long notrace sched_clock_32(void)
-{
-   u32 cyc = read_sched_clock();
-   return cyc_to_sched_clock(cyc, sched_clock_mask);
-}
-
 unsigned long long __read_mostly (*sched_clock_func)(void) = sched_clock_32;
 
 unsigned long long notrace sched_clock(void)
-- 
1.8.3.4

--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH][request for stable inclusion][3.10.x]: ARM: sched_clock: Load cycle count after epoch stabilizes

[xiaofeng.yan]

This looks applicable to stable-3.10, which load cycle count after
epoch stabilizes. The function was moved from 
arch/arm/kernel/sched_clock.c to kernel/time/sched_clock.c 
because of upgrading version. I rearrange this patch for
fixing bug in stable-3.10.
The commit id is 336ae1180df5f69b9e0fb6561bec01c5f64361cf in 3.18.
I designed a test case for recurring this bug as follows:

 CPU0   CPU1
    
 g_counter = 1;
 ...
 cyc = read_sched_clock()
 cyc_to_sched_clock()
  update_sched_clock()
   ... 
  cd.epoch_cyc = cyc;
  g_counter = 2;
  epoch_cyc = cd.epoch_cyc;
  if(g_counter == 2)
printk("error!\n");
   g_counter = 1;
  ... 
  epoch_ns + cyc_to_ns((cyc - epoch_cyc)

The bug will be proven to exist if the strings "error!" 
happen on screen. I find that "error!" happen firstly 
on screen in thirty hours.

The patch for test is as follows:
--- a/sched_clock.c2014-11-25 08:24:15.0 +
+++ b/sched_clock.c   2014-12-01 08:46:32.0 +
@@ -15,7 +15,7 @@
 #include 
 
 #include 
-
+unsigned int g_counter = 0;
 struct clock_data {
u64 epoch_ns;
u32 epoch_cyc;
@@ -68,11 +68,14 @@
 */  
do {
epoch_cyc = cd.epoch_cyc;
+   if(g_counter == 2)
+   printk("error!\n");
+   g_counter = 1;
smp_rmb();
epoch_ns = cd.epoch_ns;
smp_rmb();
} while (epoch_cyc != cd.epoch_cyc_copy);
-
+   
return epoch_ns + cyc_to_ns((cyc - epoch_cyc) & mask, cd.mult, 
cd.shift);
 }
 
@@ -99,6 +102,7 @@
cd.epoch_ns = ns; 
smp_wmb();
cd.epoch_cyc = cyc;
+   g_counter = 2;
raw_local_irq_restore(flags);
 }
 
@@ -168,6 +172,7 @@
 static unsigned long long notrace sched_clock_32(void)
 {
u32 cyc = read_sched_clock();
+   g_counter = 1;
return cyc_to_sched_clock(cyc, sched_clock_mask);
 }

xiaofeng.yan (1):
  ARM: sched_clock: Load cycle count after epoch stabilizes

 arch/arm/kernel/sched_clock.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

-- 
1.8.3.4

--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: sched_clock: Load cycle count after epoch stabilizes

[xiaofeng.yan]

From: Stephen Boyd 

There is a small race between when the cycle count is read from
the hardware and when the epoch stabilizes. Consider this
scenario:

 CPU0   CPU1
    
 cyc = read_sched_clock()
 cyc_to_sched_clock()
 update_sched_clock()
  ...
  cd.epoch_cyc = cyc;
  epoch_cyc = cd.epoch_cyc;
  ...
  epoch_ns + cyc_to_ns((cyc - epoch_cyc)

The cyc on cpu0 was read before the epoch changed. But we
calculate the nanoseconds based on the new epoch by subtracting
the new epoch from the old cycle count. Since epoch is most likely
larger than the old cycle count we calculate a large number that
will be converted to nanoseconds and added to epoch_ns, causing
time to jump forward too much.

Fix this problem by reading the hardware after the epoch has
stabilized.

Cc: Russell King 
Signed-off-by: Stephen Boyd 
Signed-off-by: John Stultz 
---
 kernel/time/sched_clock.c |   19 ---
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index aad1ae6..a326f27 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -49,10 +49,14 @@ static inline u64 notrace cyc_to_ns(u64 cyc, u32 mult, u32 
shift)
return (cyc * mult) >> shift;
 }
 
-static unsigned long long notrace cyc_to_sched_clock(u32 cyc, u32 mask)
+static unsigned long long notrace sched_clock_32(void)
 {
u64 epoch_ns;
u32 epoch_cyc;
+   u32 cyc;
+
+   if (cd.suspended)
+   return cd.epoch_ns;
 
/*
 * Load the epoch_cyc and epoch_ns atomically.  We do this by
@@ -68,7 +72,9 @@ static unsigned long long notrace cyc_to_sched_clock(u32 cyc, 
u32 mask)
smp_rmb();
} while (epoch_cyc != cd.epoch_cyc_copy);
 
-   return epoch_ns + cyc_to_ns((cyc - epoch_cyc) & mask, cd.mult, 
cd.shift);
+   cyc = read_sched_clock();
+   cyc = (cyc - epoch_cyc) & sched_clock_mask;
+   return epoch_ns + cyc_to_ns(cyc, cd.mult, cd.shift);
 }
 
 /*
@@ -160,19 +166,10 @@ void __init setup_sched_clock(u32 (*read)(void), int 
bits, unsigned long rate)
pr_debug("Registered %pF as sched_clock source\n", read);
 }
 
-static unsigned long long notrace sched_clock_32(void)
-{
-   u32 cyc = read_sched_clock();
-   return cyc_to_sched_clock(cyc, sched_clock_mask);
-}
-
 unsigned long long __read_mostly (*sched_clock_func)(void) = sched_clock_32;
 
 unsigned long long notrace sched_clock(void)
 {
-   if (cd.suspended)
-   return cd.epoch_ns;
-
return sched_clock_func();
 }
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH][request for stable inclusion][3.10.x]:ARM:sched_clock: Load cycle count after epoch stabilizes

[xiaofeng.yan]

commit 336ae1180df5f69b9e0fb6561bec01c5f64361cf 
ARM: sched_clock: Load cycle count after epoch stabilizes

This looks applicable to stable-3.10, which load cycle count after epoch 
stabilizes,
It was built successful for me. What do you think?

Stephen Boyd (1):
  ARM: sched_clock: Load cycle count after epoch stabilizes

 kernel/time/sched_clock.c |   19 ---
 1 file changed, 8 insertions(+), 11 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: sched_clock: Load cycle count after epoch stabilizes

[xiaofeng.yan]

On 2014/11/28 0:15, Greg KH wrote:

On Thu, Nov 27, 2014 at 11:15:36AM +, xiaofeng.yan wrote:

From: Stephen Boyd 

There is a small race between when the cycle count is read from
the hardware and when the epoch stabilizes. Consider this
scenario:

  CPU0   CPU1
     
  cyc = read_sched_clock()
  cyc_to_sched_clock()
  update_sched_clock()
   ...
   cd.epoch_cyc = cyc;
   epoch_cyc = cd.epoch_cyc;
   ...
   epoch_ns + cyc_to_ns((cyc - epoch_cyc)

The cyc on cpu0 was read before the epoch changed. But we
calculate the nanoseconds based on the new epoch by subtracting
the new epoch from the old cycle count. Since epoch is most likely
larger than the old cycle count we calculate a large number that
will be converted to nanoseconds and added to epoch_ns, causing
time to jump forward too much.

Fix this problem by reading the hardware after the epoch has
stabilized.

Cc: Russell King 
Signed-off-by: Stephen Boyd 
Signed-off-by: John Stultz 
---
  kernel/time/sched_clock.c |   19 ---
  1 file changed, 8 insertions(+), 11 deletions(-)

What is the git commit id of this patch in Linus's tree?

yes

And what stable tree(s) do you want it applied to?

Thanks for your reminder, I will add stable tree information.

thanks,

greg k-h

.




--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: sched_clock: Load cycle count after epoch stabilizes

[xiaofeng.yan]

From: Stephen Boyd 

There is a small race between when the cycle count is read from
the hardware and when the epoch stabilizes. Consider this
scenario:

 CPU0   CPU1
    
 cyc = read_sched_clock()
 cyc_to_sched_clock()
 update_sched_clock()
  ...
  cd.epoch_cyc = cyc;
  epoch_cyc = cd.epoch_cyc;
  ...
  epoch_ns + cyc_to_ns((cyc - epoch_cyc)

The cyc on cpu0 was read before the epoch changed. But we
calculate the nanoseconds based on the new epoch by subtracting
the new epoch from the old cycle count. Since epoch is most likely
larger than the old cycle count we calculate a large number that
will be converted to nanoseconds and added to epoch_ns, causing
time to jump forward too much.

Fix this problem by reading the hardware after the epoch has
stabilized.

Cc: Russell King 
Signed-off-by: Stephen Boyd 
Signed-off-by: John Stultz 
---
 kernel/time/sched_clock.c |   19 ---
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index aad1ae6..a326f27 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -49,10 +49,14 @@ static inline u64 notrace cyc_to_ns(u64 cyc, u32 mult, u32 
shift)
return (cyc * mult) >> shift;
 }
 
-static unsigned long long notrace cyc_to_sched_clock(u32 cyc, u32 mask)
+static unsigned long long notrace sched_clock_32(void)
 {
u64 epoch_ns;
u32 epoch_cyc;
+   u32 cyc;
+
+   if (cd.suspended)
+   return cd.epoch_ns;
 
/*
 * Load the epoch_cyc and epoch_ns atomically.  We do this by
@@ -68,7 +72,9 @@ static unsigned long long notrace cyc_to_sched_clock(u32 cyc, 
u32 mask)
smp_rmb();
} while (epoch_cyc != cd.epoch_cyc_copy);
 
-   return epoch_ns + cyc_to_ns((cyc - epoch_cyc) & mask, cd.mult, 
cd.shift);
+   cyc = read_sched_clock();
+   cyc = (cyc - epoch_cyc) & sched_clock_mask;
+   return epoch_ns + cyc_to_ns(cyc, cd.mult, cd.shift);
 }
 
 /*
@@ -160,19 +166,10 @@ void __init setup_sched_clock(u32 (*read)(void), int 
bits, unsigned long rate)
pr_debug("Registered %pF as sched_clock source\n", read);
 }
 
-static unsigned long long notrace sched_clock_32(void)
-{
-   u32 cyc = read_sched_clock();
-   return cyc_to_sched_clock(cyc, sched_clock_mask);
-}
-
 unsigned long long __read_mostly (*sched_clock_func)(void) = sched_clock_32;
 
 unsigned long long notrace sched_clock(void)
 {
-   if (cd.suspended)
-   return cd.epoch_ns;
-
return sched_clock_func();
 }
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [request for stable inclusion]:sched_clock: Load cycle count after epoch stabilizes

[xiaofeng.yan]

commit 336ae1180df5f69b9e0fb6561bec01c5f64361cf 
ARM: sched_clock: Load cycle count after epoch stabilizes

This looks applicable to stable-3.10, which load cycle count after epoch 
stabilizes,
It was built successful for me. What do you think?

Stephen Boyd (1):
  ARM: sched_clock: Load cycle count after epoch stabilizes

 kernel/time/sched_clock.c |   19 ---
 1 file changed, 8 insertions(+), 11 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

The call stack can't include the right symbol for a weak symbol in dynamic library

[xiaofeng.yan]

Hi all,

I debug program with gdb on arm platform. The environment is as follow:

platform: vexpress(virtual  machine  for 
arm on qemu)

libc: uclibc

A error information happen when debug the next codes.
0xb6fa0440 in ?? () from /lib/libc.so.0

The call stack can't include the right symbol of function pause(); I 
found that the function pause() is a weak symbol in dynamic library libc.
I don't know the reason  why gdb can't get the right symbol from the 
call stack?  Is this error from gdb or uclibc.
Is there any suggestion about this error?  I will be very grateful for 
your any reply.




code:
 relativedebug.c :
 #include 
#include 
#include 


static void handler (int signo)
{
abort ();
}

int main (void)
{
signal (SIGALRM, handler);
alarm (1);
pause ();
pause ();
return 0;
}

-bash-4.2# '/usr/bin/'gdb relativedebug
delete breakpoints
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
 

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-euler-linux-gnueabi".
For bug reporting instructions, please see:
... 


Reading symbols from /tmp/for_gdb_test/base_test/relativedebug...done.
(gdb) delete breakpoints
(gdb) break main
Breakpoint 1 at 0x8548: file relativedebug.c, line 30.
(gdb) run
Starting program: /tmp/for_gdb_test/base_test/relativedebug

Breakpoint 1, main () at relativedebug.c:30
30  signal (SIGALRM, handler);
(gdb) continue
Continuing.

Program received signal SIGABRT, Aborted.
0xb6fdb7f0 in raise () from /lib/libc.so.0
(gdb) bt
#0  0xb6fdb7f0 in raise () from /lib/libc.so.0
#1  0xb6fd5bf4 in abort () from /lib/libc.so.0^M
#2  0x8540 in handler (signo=14) at relativedebug.c:25^M
#3  ^M
#4 0xb6fa0440 in ?? () from /lib/libc.so.0
#5  0x8564 in main () at relativedebug.c:32
(gdb)

Thanks
Yan



___
bug-gdb mailing list
bug-gdb@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gdb

test

[xiaofeng.yan]

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/

[tip:sched/core] sched/deadline: Fix a precision problem in the microseconds range

[tip-bot for xiaofeng.yan]

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 precision problem in the microseconds range

An overrun could happen in function start_hrtick_dl()
when a task with SCHED_DEADLINE runs in the microseconds
range.

For example, if 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 than 1ms.

In order to achieve microsecond precision, we need to enable HRTICK feature
by the next command:

  PC#echo "HRTICK" > /sys/kernel/debug/sched_features
  PC#trace-cmd record -e sched_switch &
  PC#./schedtool -E -t 20:50:50 -e ./test

The binary test is in an endless while(1) loop here.
Some pieces of trace.dat are as follows:

  -0   157.603157: sched_switch: :R ==> 2481:4294967295: test
  test-2481  157.603203: sched_switch:  2481:R ==> 0:120: swapper/2
  -0   157.605657: sched_switch:  :R ==> 2481:4294967295: test
  test-2481  157.608183: sched_switch:  2481:R ==> 2483:120: trace-cmd
  trace-cmd-2483 157.609656: sched_switch:2483:R==>2481:4294967295: test

We can get the runtime of P1 from the information above:

  runtime = 157.608183 - 157.605657
  runtime = 0.002526(2.526ms)

The correct runtime should be less than or equal to 200us at some point.

The problem is caused by a conditional judgment "delta > 1"
in function start_hrtick_dl().

Because no hrtimer start up to control the rest of runtime
when the reset of runtime is less than 10us.

So the process will continue to run until tick-period is coming.

Move the code with the limit of the least time slice
from hrtick_start_fair() to hrtick_start() because the
EDF schedule class also needs this function in start_hrtick_dl().

To fix this problem, we call hrtimer_start() unconditionally in
start_hrtick_dl(), and make sure the scheduling slice won't be smaller
than 10us in hrtimer_start().

Signed-off-by: Xiaofeng Yan 
Reviewed-by: Li Zefan 
Acked-by: Juri Lelli 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Linus Torvalds 
Link: 
http://lkml.kernel.org/r/1409022941-5880-1-git-send-email-xiaofeng@huawei.com
[ Massaged the changelog and the code. ]
Signed-off-by: Ingo Molnar 
---
 kernel/sched/core.c | 10 +-
 kernel/sched/deadline.c |  5 +
 kernel/sched/fair.c |  8 
 3 files changed, 10 insertions(+), 13 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index a773c91..8d00f4a 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -455,7 +455,15 @@ static void __hrtick_start(void *arg)
 void hrtick_start(struct rq *rq, u64 delay)
 {
struct hrtimer *timer = &rq->hrtick_timer;
-   ktime_t time = ktime_add_ns(timer->base->get_time(), delay);
+   ktime_t time;
+   s64 delta;
+
+   /*
+* Don't schedule slices shorter than 1ns, that just
+* doesn't make sense and can cause timer DoS.
+*/
+   delta = max_t(s64, delay, 1LL);
+   time = ktime_add_ns(timer->base->get_time(), delta);
 
hrtimer_set_expires(timer, time);
 
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index d21a8e0..cc4eb89 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -997,10 +997,7 @@ static void check_preempt_curr_dl(struct rq *rq, struct 
task_struct *p,
 #ifdef CONFIG_SCHED_HRTICK
 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_start(rq, p->dl.runtime);
+   hrtick_start(rq, p->dl.runtime);
 }
 #endif
 
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 02fc949..50d2025 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3897,14 +3897,6 @@ static void hrtick_start_fair(struct rq *rq, struct 
task_struct *p)
resched_curr(rq);
return;
}
-
-   /*
-* Don't schedule slices shorter than 1ns, that just
-* doesn't make sense. Rely on vruntime for fairness.
-*/
-   if (rq->curr != p)
-   delta = max_t(s64, 1LL, delta);
-
hrtick_start(rq, delta);
}
 }
--
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/

[PATCH v4] sched/deadline: Fix the precision problem in the microsecond range

[xiaofeng.yan]

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 than 1ms.
In order to achieve microsecond precision, we need to enable HRTICK feature
by the next command.

PC#echo "HRTICK" > /sys/kernel/debug/sched_features
PC#trace-cmd record -e sched_switch &
PC#./schedtool -E -t 20:50:50 -e ./test
The binary test is in an endless while(1) loop here.
Some pieces of trace.dat are as follows:
(Remove some irrelevant information)
-0   157.603157: sched_switch: :R ==> 2481:4294967295: test
test-2481  157.603203: sched_switch:  2481:R ==> 0:120: swapper/2
-0   157.605657: sched_switch:  :R ==> 2481:4294967295: test
test-2481  157.608183: sched_switch:  2481:R ==> 2483:120: trace-cmd
trace-cmd-2483 157.609656: sched_switch:2483:R==>2481:4294967295: test

We can get a runtime of P1 from the information above.
runtime = 157.608183 - 157.605657
runtime = 0.002526(2.526ms)
The correct runtime should be less than or equal to 200us at some point.

The problem is caused by a conditional judgment "delta > 1"
in function start_hrtick_dl().
Because no hrtimer start up to control the rest of runtime
when the reset of runtime is less than 10us.
So the process will continue to run until tick-period coming.

Move the 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().

To fix this problem, we call hrtimer_start() unconditionally in 
start_hrtick_dl(),
and make sure schedule slice won't be smaller than 10us in hrtimer_start().

Signed-off-by: Xiaofeng Yan 
Reviewed-by:   Peter Zijlstra 
Reviewed-by:   Li Zefan 
Acked-by:  Juri Lelli 
---
 kernel/sched/core.c |8 +++-
 kernel/sched/deadline.c |5 +
 kernel/sched/fair.c |8 
 3 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index ec1a286..da2c6f3 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -449,8 +449,14 @@ static void __hrtick_start(void *arg)
 void hrtick_start(struct rq *rq, u64 delay)
 {
struct hrtimer *timer = &rq->hrtick_timer;
-   ktime_t time = ktime_add_ns(timer->base->get_time(), delay);
+   ktime_t time;
 
+   /*
+* Don't schedule slices shorter than 1ns, that just
+* doesn't make sense and can cause timer DoS.
+*/
+   s64 delta = max_t(s64, delay, 1LL);
+   time = ktime_add_ns(timer->base->get_time(), delta);
hrtimer_set_expires(timer, time);
 
if (rq == this_rq()) {
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 255ce13..ce52d07 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -997,10 +997,7 @@ static void check_preempt_curr_dl(struct rq *rq, struct 
task_struct *p,
 #ifdef CONFIG_SCHED_HRTICK
 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_start(rq, p->dl.runtime);
+   hrtick_start(rq, p->dl.runtime);
 }
 #endif
 
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index bfa3c86..0d6b3e6 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3892,14 +3892,6 @@ static void hrtick_start_fair(struct rq *rq, struct 
task_struct *p)
resched_curr(rq);
return;
}
-
-   /*
-* Don't schedule slices shorter than 1ns, that just
-* doesn't make sense. Rely on vruntime for fairness.
-*/
-   if (rq->curr != p)
-   delta = max_t(s64, 1LL, delta);
-
hrtick_start(rq, delta);
}
 }
-- 
1.7.9.5

--
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/

Re: [PATCH v3] sched/deadline: overrun could happen in start_hrtick_dl

[xiaofeng.yan]

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 command

PC#echo "HRTICK" > /sys/kernel/debug/sched_features
PC#trace-cmd record -e sched_switch &
PC#./schedtool -E -t 20:50 -e ./test

Some of runtime and deadline run with millisecond level by
reading kernershark. Some pieces of trace.dat are as follows:
(remove some irrelevant information)
-0   157.603157: sched_switch: :R ==> 2481:4294967295: test
test-2481  157.603203: sched_switch:  2481:R ==> 0:120: swapper/2
-0   157.605657: sched_switch:  :R ==> 2481:4294967295: test
test-2481  157.608183: sched_switch:  2481:R ==> 2483:120: trace-cmd
trace-cmd-2483 157.609656: sched_switch:2483:R==>2481:4294967295: test

We can get the runtime from the information at some point.
runtime = 157.605657 - 157.608183
runtime = 0.002526(2.526ms)
The correct runtime should be less than or equal to 200us at some point.

The problem is caused by a conditional judgment "delta > 1".
Because no hrtimer start up to control the runtime when runtime is less than 
10us.
So the process will continue to run until tick-period coming.

Move the 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().

To fix this problem, we call hrtimer_start() unconditionally in 
start_hrtick_dl(),
and make sure schedule slice won't be smaller than 10us in hrtimer_start().

Signed-off-by: Xiaofeng Yan 
Reviewed-by:   Peter Zijlstra 
Reviewed-by:   Li Zefan 

The whole changelog is very hard to read and isn't proper English, nor
is it truly explanatory. Could you please fix the changelog, or bounce
it to someone who will fix it for you?

Thanks,

Ingo


Thanks for your reply. I will fix my change log with proper English.
Thanks
Yan

.




--
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/

[PATCH v3] sched/deadline: overrun could happen in start_hrtick_dl

[xiaofeng.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 need enbale HRTICK feature by the next command
PC#echo "HRTICK" > /sys/kernel/debug/sched_features
PC#trace-cmd record -e sched_switch &
PC#./schedtool -E -t 20:50 -e ./test

Some of runtime and deadline run with millisecond level by
reading kernershark. Some pieces of trace.dat are as follows:
(remove some irrelevant information)
-0   157.603157: sched_switch: :R ==> 2481:4294967295: test
test-2481  157.603203: sched_switch:  2481:R ==> 0:120: swapper/2
-0   157.605657: sched_switch:  :R ==> 2481:4294967295: test
test-2481  157.608183: sched_switch:  2481:R ==> 2483:120: trace-cmd
trace-cmd-2483 157.609656: sched_switch:2483:R==>2481:4294967295: test

We can get the runtime from the information at some point.
runtime = 157.605657 - 157.608183
runtime = 0.002526(2.526ms)
The correct runtime should be less than or equal to 200us at some point.

The problem is caused by a conditional judgment "delta > 1".
Because no hrtimer start up to control the runtime when runtime is less than 
10us.
So the process will continue to run until tick-period coming.

Move the 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().

To fix this problem, we call hrtimer_start() unconditionally in 
start_hrtick_dl(),
and make sure schedule slice won't be smaller than 10us in hrtimer_start().

Signed-off-by: Xiaofeng Yan 
Reviewed-by:   Peter Zijlstra 
Reviewed-by:   Li Zefan 
---
 kernel/sched/core.c |8 +++-
 kernel/sched/deadline.c |5 +
 kernel/sched/fair.c |8 
 3 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 1211575..53514ba 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -449,8 +449,14 @@ static void __hrtick_start(void *arg)
 void hrtick_start(struct rq *rq, u64 delay)
 {
struct hrtimer *timer = &rq->hrtick_timer;
-   ktime_t time = ktime_add_ns(timer->base->get_time(), delay);
+   ktime_t time;
 
+   /*
+* Don't schedule slices shorter than 1ns, that just
+* doesn't make sense and can cause timer DoS.
+*/
+   s64 delta = max_t(s64, delay, 1LL);
+   time = ktime_add_ns(timer->base->get_time(), delta);
hrtimer_set_expires(timer, time);
 
if (rq == this_rq()) {
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 255ce13..ce52d07 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -997,10 +997,7 @@ static void check_preempt_curr_dl(struct rq *rq, struct 
task_struct *p,
 #ifdef CONFIG_SCHED_HRTICK
 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_start(rq, p->dl.runtime);
+   hrtick_start(rq, p->dl.runtime);
 }
 #endif
 
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index bfa3c86..0d6b3e6 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3892,14 +3892,6 @@ static void hrtick_start_fair(struct rq *rq, struct 
task_struct *p)
resched_curr(rq);
return;
}
-
-   /*
-* Don't schedule slices shorter than 1ns, that just
-* doesn't make sense. Rely on vruntime for fairness.
-*/
-   if (rq->curr != p)
-   delta = max_t(s64, 1LL, delta);
-
hrtick_start(rq, delta);
}
 }
-- 
1.7.9.5

--
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/

[tip:sched/core] sched/rt: Fix replenish_dl_entity() comments to match the current upstream code

[tip-bot for xiaofeng.yan]

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 replenish_dl_entity() comments to match the current upstream code

Signed-off-by: xiaofeng.yan 
Signed-off-by: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1404712744-16986-1-git-send-email-xiaofeng@huawei.com
Signed-off-by: Ingo Molnar 
---
 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 df0b77a..255ce13 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -306,7 +306,7 @@ static inline void setup_new_dl_entity(struct 
sched_dl_entity *dl_se,
  * the overrunning entity can't interfere with other entity in the system and
  * can't make them miss their deadlines. Reasons why this kind of overruns
  * could happen are, typically, a entity voluntarily trying to overcome its
- * runtime, or it just underestimated it during sched_setscheduler_ex().
+ * runtime, or it just underestimated it during sched_setattr().
  */
 static void replenish_dl_entity(struct sched_dl_entity *dl_se,
struct sched_dl_entity *pi_se)
--
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/

[PATCH v2] sched/deadline: overrun could happen in start_hrtick_dl

[xiaofeng.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 need enbale HRTICK feature by the next command
PC#echo "HRTICK" > /sys/kernel/debug/sched_features
PC#trace-cmd record -e sched_switch &
PC#./schedtool -E -t 20:50 -e ./test

Some of runtime and deadline run with millisecond level by
reading kernershark. Some pieces of trace.dat are as follows:
(remove some irrelevant information)
-0   157.603157: sched_switch: :R ==> 2481:4294967295: test
test-2481  157.603203: sched_switch:  2481:R ==> 0:120: swapper/2
-0   157.605657: sched_switch:  :R ==> 2481:4294967295: test
test-2481  157.608183: sched_switch:  2481:R ==> 2483:120: trace-cmd
trace-cmd-2483 157.609656: sched_switch:2483:R==>2481:4294967295: test

We can get the runtime from the information at some point.
runtime = 157.605657 - 157.608183
runtime = 0.002526(2.526ms)
The correct runtime should be less than or equal to 200us at some point.

The problem is caused by a conditional judgment "delta > 1".
Because no hrtimer start up to control the runtime when runtime is less than 
10us.
So the process will continue to run until tick-period coming.

Move the 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().

To fix this problem, we call hrtimer_start() unconditionally in 
start_hrtick_dl(),
and make sure schedule slice won't be smaller than 10us in hrtimer_start().

Signed-off-by: Xiaofeng Yan 
Reviewed-by:   Li Zefan 
---
 kernel/sched/core.c |8 +++-
 kernel/sched/deadline.c |5 +
 kernel/sched/fair.c |8 
 3 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 3bdf01b..7f066c2 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -442,8 +442,14 @@ static void __hrtick_start(void *arg)
 void hrtick_start(struct rq *rq, u64 delay)
 {
struct hrtimer *timer = &rq->hrtick_timer;
-   ktime_t time = ktime_add_ns(timer->base->get_time(), delay);
+   ktime_t time;
 
+   /*
+* Don't schedule slices shorter than 1ns, that just
+* doesn't make sense and can cause timer DoS.
+*/
+   s64 delta = max_t(s64, delay, 1LL);
+   time = ktime_add_ns(timer->base->get_time(), delta);
hrtimer_set_expires(timer, time);
 
if (rq == this_rq()) {
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index fc4f98b1..9135771 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -997,10 +997,7 @@ static void check_preempt_curr_dl(struct rq *rq, struct 
task_struct *p,
 #ifdef CONFIG_SCHED_HRTICK
 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_start(rq, p->dl.runtime);
+   hrtick_start(rq, p->dl.runtime);
 }
 #endif
 
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index fea7d33..e5cfd57 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3857,14 +3857,6 @@ static void hrtick_start_fair(struct rq *rq, struct 
task_struct *p)
resched_task(p);
return;
}
-
-   /*
-* Don't schedule slices shorter than 1ns, that just
-* doesn't make sense. Rely on vruntime for fairness.
-*/
-   if (rq->curr != p)
-   delta = max_t(s64, 1LL, delta);
-
hrtick_start(rq, delta);
}
 }
-- 
1.7.9.5

--
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/

[PATCH v2] sched/deadline: overrun could happen in start_hrtick_dl

[xiaofeng.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 need enbale HRTICK feature by the next command
PC#echo "HRTICK" > /sys/kernel/debug/sched_features
PC#trace-cmd record -e sched_switch &
PC#./schedtool -E -t 20:50 -e ./test

Some of runtime and deadline run with millisecond level by
reading kernershark. Some pieces of trace.dat are as follows:
(remove some irrelevant information)
-0   157.603157: sched_switch: :R ==> 2481:4294967295: test
test-2481  157.603203: sched_switch:  2481:R ==> 0:120: swapper/2
-0   157.605657: sched_switch:  :R ==> 2481:4294967295: test
test-2481  157.608183: sched_switch:  2481:R ==> 2483:120: trace-cmd
trace-cmd-2483 157.609656: sched_switch:2483:R==>2481:4294967295: test

We can get the runtime from the information at some point.
runtime = 157.605657 - 157.608183
runtime = 0.002526(2.526ms)
The correct runtime should be less than or equal to 200us at some point.

The problem is caused by a conditional judgment "delta > 1".
Because no hrtimer start up to control the runtime when runtime is less than 
10us.
So the process will continue to run until tick-period coming.

Move the 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().

To fix this problem, we call hrtimer_start() unconditionally in 
start_hrtick_dl(),
and make sure schedule slice won't be smaller than 10us in hrtimer_start().

Signed-off-by: Xiaofeng Yan 
Reviewed-by:   Li Zefan 
---
 kernel/sched/core.c |8 +++-
 kernel/sched/deadline.c |5 +
 kernel/sched/fair.c |8 
 3 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 3bdf01b..7f066c2 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -442,8 +442,14 @@ static void __hrtick_start(void *arg)
 void hrtick_start(struct rq *rq, u64 delay)
 {
struct hrtimer *timer = &rq->hrtick_timer;
-   ktime_t time = ktime_add_ns(timer->base->get_time(), delay);
+   ktime_t time;
 
+   /*
+* Don't schedule slices shorter than 1ns, that just
+* doesn't make sense and can cause timer DoS.
+*/
+   s64 delta = max_t(s64, delay, 1LL);
+   time = ktime_add_ns(timer->base->get_time(), delta);
hrtimer_set_expires(timer, time);
 
if (rq == this_rq()) {
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index fc4f98b1..9135771 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -997,10 +997,7 @@ static void check_preempt_curr_dl(struct rq *rq, struct 
task_struct *p,
 #ifdef CONFIG_SCHED_HRTICK
 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_start(rq, p->dl.runtime);
+   hrtick_start(rq, p->dl.runtime);
 }
 #endif
 
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index fea7d33..e5cfd57 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3857,14 +3857,6 @@ static void hrtick_start_fair(struct rq *rq, struct 
task_struct *p)
resched_task(p);
return;
}
-
-   /*
-* Don't schedule slices shorter than 1ns, that just
-* doesn't make sense. Rely on vruntime for fairness.
-*/
-   if (rq->curr != p)
-   delta = max_t(s64, 1LL, delta);
-
hrtick_start(rq, delta);
}
 }
-- 
1.7.9.5

--
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/

[PATCH] sched/core: Limit the least time slice in hrtick_start()

[xiaofeng.yan]

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 of process when left runtime is
less than 10us.

The goal is to fix this bug from start_hrtick_dl() and reduce code redundancy.

Signed-off-by: Xiaofeng Yan 
Reviewed-by:   Li Zefan 
---
 kernel/sched/core.c |8 +++-
 kernel/sched/deadline.c |5 +
 kernel/sched/fair.c |8 
 3 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 3bdf01b..7f066c2 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -442,8 +442,14 @@ static void __hrtick_start(void *arg)
 void hrtick_start(struct rq *rq, u64 delay)
 {
struct hrtimer *timer = &rq->hrtick_timer;
-   ktime_t time = ktime_add_ns(timer->base->get_time(), delay);
+   ktime_t time;
 
+   /*
+* Don't schedule slices shorter than 1ns, that just
+* doesn't make sense and can cause timer DoS.
+*/
+   s64 delta = max_t(s64, delay, 1LL);
+   time = ktime_add_ns(timer->base->get_time(), delta);
hrtimer_set_expires(timer, time);
 
if (rq == this_rq()) {
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index fc4f98b1..9135771 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -997,10 +997,7 @@ static void check_preempt_curr_dl(struct rq *rq, struct 
task_struct *p,
 #ifdef CONFIG_SCHED_HRTICK
 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_start(rq, p->dl.runtime);
+   hrtick_start(rq, p->dl.runtime);
 }
 #endif
 
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index fea7d33..e5cfd57 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3857,14 +3857,6 @@ static void hrtick_start_fair(struct rq *rq, struct 
task_struct *p)
resched_task(p);
return;
}
-
-   /*
-* Don't schedule slices shorter than 1ns, that just
-* doesn't make sense. Rely on vruntime for fairness.
-*/
-   if (rq->curr != p)
-   delta = max_t(s64, 1LL, delta);
-
hrtick_start(rq, delta);
}
 }
-- 
1.7.9.5

--
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/

Re: [PATCH] sched/deadline: overrun could happen in start_hrtick_dl

[xiaofeng.yan]

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 later.


--
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/

Re: [PATCH] sched/deadline: overrun could happen in start_hrtick_dl

[xiaofeng.yan]

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 > 1)
-hrtick_start(rq, p->dl.runtime);
+delta = max_t(s64, 1LL, delta);
+hrtick_start(rq, delta);
  }

no, no, no. I said to unify the test.


I understand your idea after reading the next patch. This is good 
solution.

I will test it with your patch.



I have tested this solution, It can work very well with deadline 
schedule class.


 kernel/sched/core.c |9 -
 kernel/sched/deadline.c |5 +
 kernel/sched/fair.c |8 
 3 files changed, 9 insertions(+), 13 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 3bdf01b..cc9a058 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -442,8 +442,15 @@ static void __hrtick_start(void *arg)
 void hrtick_start(struct rq *rq, u64 delay)
 {
struct hrtimer *timer = &rq->hrtick_timer;
-   ktime_t time = ktime_add_ns(timer->base->get_time(), delay);

+   ktime_t time;
+
+   /*
+* Don't schedule slices shorter than 1ns, that just
+* doesn't make sense and can cause timer DoS.
+*/
+   s64 delta = max_t(s64, delay, 1LL);
+   time = ktime_add_ns(timer->base->get_time(), delta);
hrtimer_set_expires(timer, time);

if (rq == this_rq()) {
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index fc4f98b1..9135771 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -997,10 +997,7 @@ static void check_preempt_curr_dl(struct rq *rq, 
struct task_struct *p,

 #ifdef CONFIG_SCHED_HRTICK
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_start(rq, p->dl.runtime);
+   hrtick_start(rq, p->dl.runtime);
 }
 #endif

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index fea7d33..e5cfd57 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3857,14 +3857,6 @@ static void hrtick_start_fair(struct rq *rq, 
struct task_struct *p)

resched_task(p);
return;
}
-
-   /*
-* Don't schedule slices shorter than 1ns, that just
-* doesn't make sense. Rely on vruntime for fairness.
-*/
-   if (rq->curr != p)
-   delta = max_t(s64, 1LL, delta);
-
hrtick_start(rq, delta);
}
 }
--



---
  kernel/sched/core.c | 9 -
  kernel/sched/deadline.c | 3 +--
  kernel/sched/fair.c | 7 ---
  3 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index e1a2f31bb0cb..c7b8a6fbac66 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -444,7 +444,14 @@ static void __hrtick_start(void *arg)
  void hrtick_start(struct rq *rq, u64 delay)
  {
  struct hrtimer *timer = &rq->hrtick_timer;
-ktime_t time = ktime_add_ns(timer->base->get_time(), delay);
+ktime_t time;
+
+/*
+ * Don't schedule slices shorter than 1ns, that just
+ * doesn't make sense and can cause timer DoS.
+ */
+delta = max_t(s64, delta, 1LL);


transfer the argument delta to delay


+time = ktime_add_ns(timer->base->get_time(), delay);
hrtimer_set_expires(timer, time);
  diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index fc4f98b1258f..e1e24eea8061 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -999,8 +999,7 @@ 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_start(rq, p->dl.runtime);
+hrtick_start(rq, p->dl.runtime);
  }
  #endif
  diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 923fe32db6b3..713c58d2a7b0 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3901,13 +3901,6 @@ static void hrtick_start_fair(struct rq *rq, 
struct task_struct *p)

  return;
  }
  -/*
- * Don't schedule slices shorter than 1ns, that just
- * doesn't make sense. Rely on vruntime for fairness.
- */
-if (rq->curr != p)
-delta = max_t(s64, 1LL, delta);
-
  hrtick_start(rq, delta);
  }
  }



--
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/

.

Re: [PATCH] sched/deadline: overrun could happen in start_hrtick_dl

[xiaofeng.yan]

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_start(rq, p->dl.runtime);
+   delta = max_t(s64, 1LL, delta);
+   hrtick_start(rq, delta);
  }

no, no, no. I said to unify the test.


I understand your idea after reading the next patch. This is good solution.
I will test it with your patch.


---
  kernel/sched/core.c | 9 -
  kernel/sched/deadline.c | 3 +--
  kernel/sched/fair.c | 7 ---
  3 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index e1a2f31bb0cb..c7b8a6fbac66 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -444,7 +444,14 @@ static void __hrtick_start(void *arg)
  void hrtick_start(struct rq *rq, u64 delay)
  {
struct hrtimer *timer = &rq->hrtick_timer;
-   ktime_t time = ktime_add_ns(timer->base->get_time(), delay);
+   ktime_t time;
+
+   /*
+* Don't schedule slices shorter than 1ns, that just
+* doesn't make sense and can cause timer DoS.
+*/
+   delta = max_t(s64, delta, 1LL);


transfer the argument delta to delay


+   time = ktime_add_ns(timer->base->get_time(), delay);
  
  	hrtimer_set_expires(timer, time);
  
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c

index fc4f98b1258f..e1e24eea8061 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -999,8 +999,7 @@ 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_start(rq, p->dl.runtime);
+   hrtick_start(rq, p->dl.runtime);
  }
  #endif
  
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c

index 923fe32db6b3..713c58d2a7b0 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3901,13 +3901,6 @@ static void hrtick_start_fair(struct rq *rq, struct 
task_struct *p)
return;
}
  
-		/*

-* Don't schedule slices shorter than 1ns, that just
-* doesn't make sense. Rely on vruntime for fairness.
-*/
-   if (rq->curr != p)
-   delta = max_t(s64, 1LL, delta);
-
hrtick_start(rq, delta);
}
  }



--
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/

[PATCH] sched/deadline: overrun could happen in start_hrtick_dl

[xiaofeng.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 need enbale HRTICK feature by the next command
PC#echo "HRTICK" > /sys/kernel/debug/sched_features
PC#trace-cmd record -e sched_switch &
PC#./schedtool -E -t 20:50 -e ./test

Some of runtime and deadline run with millisecond level by
reading kernershark. Some pieces of trace.dat are as follows:
(remove some irrelevant information)
-0   157.603157: sched_switch: :R ==> 2481:4294967295: test
test-2481  157.603203: sched_switch:  2481:R ==> 0:120: swapper/2
-0   157.605657: sched_switch:  :R ==> 2481:4294967295: test
test-2481  157.608183: sched_switch:  2481:R ==> 2483:120: trace-cmd
trace-cmd-2483 157.609656: sched_switch:2483:R==>2481:4294967295: test

We can get the runtime from the information at some point.
runtime = 157.605657 - 157.608183
runtime = 0.002526(2.526ms)
The correct runtime should be less than or equal to 200us at some point.

The problem is caused by a conditional judgment "delta > 1".
Because no hrtimer start up to control the runtime when 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 |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index fc4f98b1..51e6b0e 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -997,10 +997,8 @@ static void check_preempt_curr_dl(struct rq *rq, struct 
task_struct *p,
 #ifdef CONFIG_SCHED_HRTICK
 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_start(rq, p->dl.runtime);
+   s64 delta = max_t(s64, 1LL, p->dl.runtime);
+   hrtick_start(rq, delta);
 }
 #endif
 
-- 
1.7.9.5

--
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/

Re: [PATCH] sched/deadline: overrun could happen in start_hrtick_dl

[xiaofeng.yan]

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 need enbale HRTICK feature by the next command
PC#echo "HRTICK" > /sys/kernel/debug/sched_features
PC#trace-cmd record -e sched_switch &
PC#./schedtool -E -t 20:50 -e ./test

Some of runtime and deadline run with millisecond level by
reading kernershark. Some pieces of trace.dat are as follows:
(remove some irrelevant information)
-0   157.603157: sched_switch: :R ==> 2481:4294967295: test
test-2481  157.603203: sched_switch:  2481:R ==> 0:120: swapper/2
-0   157.605657: sched_switch:  :R ==> 2481:4294967295: test
test-2481  157.608183: sched_switch:  2481:R ==> 2483:120: trace-cmd
trace-cmd-2483 157.609656: sched_switch:2483:R==>2481:4294967295: test

We can get the runtime from the information at some point.
runtime = 157.605657 - 157.608183
runtime = 0.002526(2.526ms)
The correct runtime should be less than or equal to 200us at some point.

The problem is caused by a conditional judgment "delta > 1".
Because no hrtimer start up to control the runtime when 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 |6 ++
  1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index fc4f98b1..b71c229 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -997,10 +997,8 @@ static void check_preempt_curr_dl(struct rq *rq, struct 
task_struct *p,
  #ifdef CONFIG_SCHED_HRTICK
  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_start(rq, p->dl.runtime);
+   delta = max_t(s64, 1LL, delta);
+   hrtick_start(rq, delta);
  }
  #endif
  



--
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/

[PATCH] sched/deadline: overrun could happen in start_hrtick_dl

[xiaofeng.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 need enbale HRTICK feature by the next command
PC#echo "HRTICK" > /sys/kernel/debug/sched_features
PC#trace-cmd record -e sched_switch &
PC#./schedtool -E -t 20:50 -e ./test

Some of runtime and deadline run with millisecond level by
reading kernershark. Some pieces of trace.dat are as follows:
(remove some irrelevant information)
-0   157.603157: sched_switch: :R ==> 2481:4294967295: test
test-2481  157.603203: sched_switch:  2481:R ==> 0:120: swapper/2
-0   157.605657: sched_switch:  :R ==> 2481:4294967295: test
test-2481  157.608183: sched_switch:  2481:R ==> 2483:120: trace-cmd
trace-cmd-2483 157.609656: sched_switch:2483:R==>2481:4294967295: test

We can get the runtime from the information at some point.
runtime = 157.605657 - 157.608183
runtime = 0.002526(2.526ms)
The correct runtime should be less than or equal to 200us at some point.

The problem is caused by a conditional judgment "delta > 1".
Because no hrtimer start up to control the runtime when 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 |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index fc4f98b1..b71c229 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -997,10 +997,8 @@ static void check_preempt_curr_dl(struct rq *rq, struct 
task_struct *p,
 #ifdef CONFIG_SCHED_HRTICK
 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_start(rq, p->dl.runtime);
+   delta = max_t(s64, 1LL, delta);
+   hrtick_start(rq, delta);
 }
 #endif
 
-- 
1.7.9.5

--
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/

Re: [PATCH] sched/rt: overrun could happen in start_hrtick_dl

[xiaofeng.yan]

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 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#./schedtool -E -t 20:50 -e ./test&
PC#trace-cmd record -e sched_switch

Are you actually using HRTICK ?

yes, If HRTICK is close , then all of runtime and deadline will be wrong.

I think what peter meant is, do you use HRTICK in products or
just use it for testing/experiment?


Thanks for your timely comments. In fact, We use HRTICK feature in product.
We need microsecond level
precision.

Ah, thanks. Be advised that currently HRTICK is rather expensive. The
cost is twofold: 1) doing all the kernel side hrtimer things and 2)
programming clock hardware.

Of course, if that's what you need, you're willing to pay the price.

I'll see if I can put making it less expensive slightly higher on the
(endless) todo list.


another fold: 3) Frequent migration  :)
In fact, frequent migration lead to higher overload.  In our product  we 
design new migration solution.

The simple description is as follow:
1 Set affinity in user space program at the beginning
2 Migrate happen per 100ms
3 Free task (runtime < dl_runtime)is migrated to free cpu (rt task 
bandwidth < 65%) .

4 Busy task will run more time in a CPU by dynamic quota.
So the condition of migration depends on whether task is busy or idle or 
not instead of deadline at some point.

This could not meet EDF requirement but meet our product :)







--
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/

Re: [PATCH] sched/rt: overrun could happen in start_hrtick_dl

[xiaofeng.yan]

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 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#./schedtool -E -t 20:50 -e ./test&
PC#trace-cmd record -e sched_switch

Are you actually using HRTICK ?

yes, If HRTICK is close , then all of runtime and deadline will be wrong.

I think what peter meant is, do you use HRTICK in products or
just use it for testing/experiment?

Thanks for your timely comments. In fact, We use HRTICK feature in 
product. We need microsecond level

precision.

Thanks
Yan

.




--
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/

Re: [PATCH] sched/rt: overrun could happen in start_hrtick_dl

[xiaofeng.yan]

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 need enbale HRTICK feature by the next command
PC#echo "HRTICK" > /sys/kernel/debug/sched_features
PC#./schedtool -E -t 20:50 -e ./test&
PC#trace-cmd record -e sched_switch

Are you actually using HRTICK ?

yes, If HRTICK is close , then all of runtime and deadline will be wrong.

Some of runtime and deadline run with millisecond level by
reading kernershark.
The problem is caused by a conditional judgment "delta > 1".
Because no hrtimer start up to control the runtime when 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 

Always when sending patches for deadline, also CC Juri.


---
  kernel/sched/deadline.c |6 ++
  1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index fc4f98b1..dfefa82 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -997,10 +997,8 @@ static void check_preempt_curr_dl(struct rq *rq, struct 
task_struct *p,
  #ifdef CONFIG_SCHED_HRTICK
  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_start(rq, p->dl.runtime);
+   s64 delta = p->dl.runtime > 1 ? p->dl.runtime : 1;
+   hrtick_start(rq, delta);

Yeah, that looks funny. And seeing how the only other user does
something similar:

hrtick_start_fair()
delta = max(1ULL, delta)
hrtick_start(rq, delta)

I will modify my code according to your suggest.


Does it make sense to move this max() into hrtick_start()?

Also; and I don't think you mentioned that but did fix, the argument to
hrtick_start() is wrong, it should be the delta, not the absolute
timeout.
Perhaps , if the runtime  is less than 10us,  the context switch 
overhead for system could be closed to 10us.

So it could loss more then you gain.

Thanks for your reply.

Thanks
Yan

--
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/

[PATCH] sched/rt:Fix replenish_dl_entity() comments to match the current upstream code

[xiaofeng.yan]

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 inline void setup_new_dl_entity(struct 
sched_dl_entity *dl_se,
  * the overrunning entity can't interfere with other entity in the system and
  * can't make them miss their deadlines. Reasons why this kind of overruns
  * could happen are, typically, a entity voluntarily trying to overcome its
- * runtime, or it just underestimated it during sched_setscheduler_ex().
+ * runtime, or it just underestimated it during sched_setattr().
  */
 static void replenish_dl_entity(struct sched_dl_entity *dl_se,
struct sched_dl_entity *pi_se)
-- 
1.7.9.5

--
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/

[PATCH] sched/rt: overrun could happen in start_hrtick_dl

[xiaofeng.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 need enbale HRTICK feature by the next command
PC#echo "HRTICK" > /sys/kernel/debug/sched_features
PC#./schedtool -E -t 20:50 -e ./test&
PC#trace-cmd record -e sched_switch

Some of runtime and deadline run with millisecond level by
reading kernershark.
The problem is caused by a conditional judgment "delta > 1".
Because no hrtimer start up to control the runtime when 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 |6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index fc4f98b1..dfefa82 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -997,10 +997,8 @@ static void check_preempt_curr_dl(struct rq *rq, struct 
task_struct *p,
 #ifdef CONFIG_SCHED_HRTICK
 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_start(rq, p->dl.runtime);
+   s64 delta = p->dl.runtime > 1 ? p->dl.runtime : 1;
+   hrtick_start(rq, delta);
 }
 #endif
 
-- 
1.7.9.5

--
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/

Re: [RFD] sched/deadline: EDF dynamic quota design

[xiaofeng.yan]

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 proposed to merge it in 
SCHED_DEADLINE.
But maybe there can be some trade-off between the "exact 
compliance with the
GRUB algorithm" and implementation efficiency that can make it 
acceptable...



Has these  codes been opened about the implementation in some 
community or not ?
The old GRUB scheduler for Linux was used for some experiments 
published in a paper
at RTLWS 2007, and of course the code was open-source (released 
under GPL).
It required a patch for the Linux kernel (I used a 2.6.something 
kernel) which allowed
to load the scheduler as a kernel module (yes, I know this is the 
wrong way to go...

But implementing it like this was simpler :).
That is very old code... I probably still have it somewhere, but I 
have to search
for it. If someone is interested, I can try to search (the story of 
the user-space
daemon for adaptive reservations is similar: I released it as 
open-source years ago...

If anyone is interested I can search for this code too)


Luca

I'm glad that you reply this email.  yes, I'm so interesting about 
your solution.  In fact , there are scenarios
in our product.  Could you send me a link if you have?  I can test 
your solution in our scene if you like.

Ok, so I found my old code for the CBS scheduler with GRUB modifications.
You can get it from here: 
http://disi.unitn.it/~abeni/old-cbs-scheduler.tgz


Please note that:
1) This is old code (for 2.6.x kernels), written before SCHED_DEADLINE 
development

   was started
2) The scheduler architecture is completely different respect to the 
current one,
   but the basic scheduling algorithm implemented by my old scheduler 
is the same
   one implemented by SCHED_DEADLINE (but I did not implement 
multi-processor support :)
3) You can have a look at the modifications needed to implement GRUB 
by simply grepping
   for "GRUB" in the source code. Basically, the algorithm is 
implemented by:
   1) Implementing a state machine to keep track of the current state 
of a task (is it
  using its reserved fraction of CPU time, did it already use such 
a fraction of CPU
  time, or is it not using any CPU time?). This is done by adding 
a "state" field in

  "cbs_struct", and properly updating it in cbs.c
   2) Keeping track of the total fraction of CPU time used by the 
active tasks. See the "U"
  variable in cbs.c (in a modern scheduler, it should probably 
become a field in the

  runqueue structure)
   3) Modifying the rule used to update the runtime. For a "standard" 
CBS without CPU
  reclaiming (the one implemented by SCHED_DEADLINE), if a task 
executes for an amount
  of time "delta" its runtime must be decreased by delta. For 
GRUB, it must be decreased

  by "delta" mutliplied by U. See "account()" in cbs.c.
  The "trick" is in properly updating U (and this is done using 
the state machine

  mentioned above)

Summing up, this code is not directly usable, but it shows you what 
needs to be done in
order to implement the GRUB mechanism for CPU reclaiming in a CBS 
scheduler...



Thanks for giving me your solution. I will take a look at it and modify 
it in our scene later.


Thanks
Yan


Luca

.




--
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/

Re: [RFD] sched/deadline: EDF dynamic quota design

[xiaofeng.yan]

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 every period
- You can also define a maximum fraction Umax of the CPU time that the
  SCHED_DEADLINE tasks can use. Note that Umax _must_ be larger or 
equal

  than sum_i runtime_i / period_i
  (note: in the original GRUB paper, only one CPU is considered, and 
Umax is

  set equal to 1)
- If the tasks are consuming less than Umax, then the scheduling 
algorithm
  allows them to use more runtime (but not less than the guaranteed 
runtime_i)

  in order to use up to Umax.
  This is achieved by modifying the rule used to decrease the 
runtime: in
  SCHED_DEADLINE, if a task executes for a time delta, its runtime 
is decreased
  by delta; using GRUB, it would be decreased by a smaller amount of 
time

  (computed based on Umax, on the active SCHED_DEADLINE tasks, etc...).
  This requires to implement some kind of state machine (the details 
are in

  the GRUB paper)

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 proposed to merge it in 
SCHED_DEADLINE.
But maybe there can be some trade-off between the "exact compliance 
with the
GRUB algorithm" and implementation efficiency that can make it 
acceptable...



Has these  codes been opened about the implementation in some 
community or not ?
The old GRUB scheduler for Linux was used for some experiments 
published in a paper
at RTLWS 2007, and of course the code was open-source (released under 
GPL).
It required a patch for the Linux kernel (I used a 2.6.something 
kernel) which allowed
to load the scheduler as a kernel module (yes, I know this is the 
wrong way to go...

But implementing it like this was simpler :).
That is very old code... I probably still have it somewhere, but I 
have to search
for it. If someone is interested, I can try to search (the story of 
the user-space
daemon for adaptive reservations is similar: I released it as 
open-source years ago...

If anyone is interested I can search for this code too)


Luca

I'm glad that you reply this email.  yes, I'm so interesting about your 
solution.  In fact , there are scenarios
in our product.  Could you send me a link if you have?  I can test your 
solution in our scene if you like.


Thanks
Yan





--
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/

Re: [RFD] sched/deadline: EDF dynamic quota design

[xiaofeng.yan]

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
scheduler)
by having a daemon that monitors the SCHED_DEADLINE tasks and changes
their
runtimes based on some kind of feedback (for example, difference
between the
scheduling deadline of a task and its actual deadline - if this
information
is made available by the scheduler). I developed a similar
implementation in
the past (not based on SCHED_DEADLINE, but on some previous
implementation
of the CBS algorithm).


This sounds like a very slow approach. What if the extra BW given by 
T2 was
for one period only? There's no way you could create a userspace 
daemon to

handle that kind of budget-tweaking.
Right. With "This can also be implemented in user-space..." I was 
referring
to the feedback scheduling (adaptive reservation) approach, which is 
designed
to "auto-tune" the reservation budget following slower variations (it 
is like
a low-pass filter, which can set the budget to something between the 
average
used budget and the largest one). Basically, it works on a larger time 
scale.
If you want a "per-period" runtime donation, you need a reclaiming 
mechanism

like GRUB, CASH, or similar, which needs to be implemented in the kernel.



Also, it sounds like a *really* dangerous idea to let some random (tm)
userspace daemon adjust the deadline-budget for other tasks in the 
system

based on an observation of spent budget for the last X seconds. It's not
military funding we're concerned with here.

When you state your WCET, it is not because you need -exactly- that 
budget,

it is because you should *never* exceed that kind of rquired
computational time.
Exact. But the idea of feedback scheduling was that sometimes you do 
not know
the WCET... You can guess it, or measure it over a large number of 
runs (but

the Murphy law ensures that you will miss the worst case anyway ;-).
And there are situations in which you do not need to respect all of the
deadlines... The daemon I was talking about just monitors the 
difference between
the scheduling deadline and the "real job deadline" for some tasks, in 
order to
understand if the runtime they have been assigned is enough or not... 
If some
task is not receiving enough runtime (that is, if the difference 
between its
scheduling deadline and the "real deadline" becomes too large), the 
daemon
tries to increase its runtime. When the system is overloaded (that is, 
everyone
of the monitored tasks wants too much runtime, and the admission 
control fails),

the daemon decreases the runtimes according to the weight of the tasks...
Of course, the daemon does not have to monitor all of the 
SCHED_DEADLINE tasks
in the system, but only the ones for which adaptive reservations are 
useful
(tasks for which the WCET is not known for sure, and that can 
tollerate some
missed deadlines). The other SCHED_DEADLINE tasks can stay with their 
fixed

runtimes unchanged.



Blindly reducing allocated runtime is defeating that whole purpose.

Of course, there could be a minimum guaranteed runtime per task.


Granted, if you use EDF for BW-control only, it could be done - but then
the thread itself should do that. Real-time is not about being fair. 
Heck,

it's not even about being optimal, it's about being predictable and
"dynamically adjusting" is not!
Well, this could lead to a long discussion, in which everyone is right 
and
everyone is wrong... Let's say that it depends on the applications 
requirements

and constraints.

[...]

Will EDF has dynamic quota in future?


Well, as Luca said, you can already use SCHED_DEADLINE as the backend
for feedback scheduling (that pertain mostly to user-space).

And yes, there are already thoughts to modify it a bit to go towards
Lipari's et al. GRUB algorithm. That would be probably helpful in
situations like yours. But I can't give you any timing for it.


Need to read up on GRUB before involving myself in this part of the
discussion, but I'm not sure how much I enjoy the idea of some part of
userspace (more or less) blindly adjusting deadline-params for other 
tasks.
No, GRUB does not involve the user-space adjusting any scheduling 
parameter.

GRUB is a reclaiming algorithm, which works in a different way respect to
the feedback scheduling approach I described, and requires 
modifications in

the scheduler.
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 every period
- You can also define a maximum fraction Umax of the CPU time that the
  SCHED_DEADLINE tasks can use. Note that Umax _must_ be larger or equal
  than sum_i runtime_i / period_i
  (note: in the original GRUB paper, only one CPU is consi

[tip:sched/core] sched/rt: Fix 'struct sched_dl_entity' and dl_task_time() comments, to match the current upstream code

[tip-bot for xiaofeng.yan]

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 'struct sched_dl_entity' and dl_task_time() comments, to match 
the current upstream code

Signed-off-by: xiaofeng.yan 
Signed-off-by: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1399605687-18094-1-git-send-email-xiaofeng@huawei.com
Signed-off-by: Ingo Molnar 
---
 include/linux/sched.h   | 4 ++--
 kernel/sched/deadline.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 725eef1..0f91d00 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1175,8 +1175,8 @@ struct sched_dl_entity {
 
/*
 * Original scheduling parameters. Copied here from sched_attr
-* during sched_setscheduler2(), they will remain the same until
-* the next sched_setscheduler2().
+* during sched_setattr(), they will remain the same until
+* the next sched_setattr().
 */
u64 dl_runtime; /* maximum runtime for each instance*/
u64 dl_deadline;/* relative deadline of each instance   */
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index e0a04ae..f9ca7d1 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -520,7 +520,7 @@ static enum hrtimer_restart dl_task_timer(struct hrtimer 
*timer)
 * We need to take care of a possible races here. In fact, the
 * task might have changed its scheduling policy to something
 * different from SCHED_DEADLINE or changed its reservation
-* parameters (through sched_setscheduler()).
+* parameters (through sched_setattr()).
 */
if (!dl_task(p) || dl_se->dl_new)
goto unlock;
--
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/

[tip:sched/core] sched/rt: Fix a comment in deadline.c

[tip-bot for xiaofeng.yan]

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 comment in deadline.c

EDF use sched_setattr() instead of sched_setscheduler().

Cc: mi...@redhat.com
Signed-off-by: xiaofeng.yan 
Signed-off-by: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1399880477-23376-1-git-send-email-xiaofeng@huawei.com
Signed-off-by: Thomas Gleixner 
---
 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 e0a04ae..f9ca7d1 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -520,7 +520,7 @@ static enum hrtimer_restart dl_task_timer(struct hrtimer 
*timer)
 * We need to take care of a possible races here. In fact, the
 * task might have changed its scheduling policy to something
 * different from SCHED_DEADLINE or changed its reservation
-* parameters (through sched_setscheduler()).
+* parameters (through sched_setattr()).
 */
if (!dl_task(p) || dl_se->dl_new)
goto unlock;
--
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/

[tip:sched/core] sched/rt: Fix a comment in struct sched_dl_entity

[tip-bot for xiaofeng.yan]

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 in struct sched_dl_entity

Change sched_setscheduler2() to sched_setattr() in the comments.
There isn't function sched_setscheduler2() in the main line.
The previous EDF version defines this function
before being merged into the main line.
User should use sched_setattr() instead of
sched_setscheduler2() now.

Cc: mi...@redhat.com
Signed-off-by: xiaofeng.yan 
Signed-off-by: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1399605687-18094-1-git-send-email-xiaofeng@huawei.com
Signed-off-by: Thomas Gleixner 
---
 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 725eef1..0f91d00 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1175,8 +1175,8 @@ struct sched_dl_entity {
 
/*
 * Original scheduling parameters. Copied here from sched_attr
-* during sched_setscheduler2(), they will remain the same until
-* the next sched_setscheduler2().
+* during sched_setattr(), they will remain the same until
+* the next sched_setattr().
 */
u64 dl_runtime; /* maximum runtime for each instance*/
u64 dl_deadline;/* relative deadline of each instance   */
--
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/

[PATCH] sched/rt: Fix a comment in deadline.c

[xiaofeng.yan]

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
+++ b/kernel/sched/deadline.c
@@ -520,7 +520,7 @@ static enum hrtimer_restart dl_task_timer(struct hrtimer 
*timer)
 * We need to take care of a possible races here. In fact, the
 * task might have changed its scheduling policy to something
 * different from SCHED_DEADLINE or changed its reservation
-* parameters (through sched_setscheduler()).
+* parameters (through sched_setattr()).
 */
if (!dl_task(p) || dl_se->dl_new)
goto unlock;
-- 
1.7.9.5

--
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/

[PATCH] sched/rt: Fix a comment in struct sched_dl_entity

[xiaofeng.yan]

Change sched_setscheduler2() to sched_setattr() in the comments.
There isn't function sched_setscheduler2() in the main line.
The previous EDF version defines this function
before being merged into the main line.
User should use sched_setattr() instead of
sched_setscheduler2() 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..ed64468 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1123,8 +1123,8 @@ struct sched_dl_entity {
 
/*
 * Original scheduling parameters. Copied here from sched_attr
-* during sched_setscheduler2(), they will remain the same until
-* the next sched_setscheduler2().
+* during sched_setattr(), they will remain the same until
+* the next sched_setattr().
 */
u64 dl_runtime; /* maximum runtime for each instance*/
u64 dl_deadline;/* relative deadline of each instance   */
-- 
1.7.9.5

--
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/

Re: [PATCH] sched/rt: Fix a comment in struct sched_dl_entity

[xiaofeng.yan]

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 being merged into the main line.
User should use sched_setscheduler() instead of
sched_setscheduler2() now.

Nah, you fail.. the interface is now called sched_setattr()



thanks for your reply. I will  push new patch according to your suggest.

Thanks
xiaofeng.yan

--
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/

[PATCH] sched/rt: Fix a comment in struct sched_dl_entity

[xiaofeng.yan]

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 being merged into the main line.
User should use sched_setscheduler() instead of
sched_setscheduler2() 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 @@ struct sched_dl_entity {
 
/*
 * Original scheduling parameters. Copied here from sched_attr
-* during sched_setscheduler2(), they will remain the same until
-* the next sched_setscheduler2().
+* during sched_setscheduler(), they will remain the same until
+* the next sched_setscheduler().
 */
u64 dl_runtime; /* maximum runtime for each instance*/
u64 dl_deadline;/* relative deadline of each instance   */
-- 
1.7.9.5

--
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/

[OE-core] [PATCH 3/3] lsbinitscripts: Add the header for functions.patch

[xiaofeng.yan]

From: Xiaofeng Yan 

Add upstream-status and signed-off-by to functions.patch

Signed-off-by: Xiaofeng Yan 
---
 .../lsb/lsbinitscripts/functions.patch |3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-extended/lsb/lsbinitscripts/functions.patch 
b/meta/recipes-extended/lsb/lsbinitscripts/functions.patch
index aa63cec..6d09d05 100644
--- a/meta/recipes-extended/lsb/lsbinitscripts/functions.patch
+++ b/meta/recipes-extended/lsb/lsbinitscripts/functions.patch
@@ -1,3 +1,6 @@
+Upstream-Status: Inappropriate [configuration]
+
+Signed-off-by: Xiaofeng Yan 
 --- a/rc.d/init.d/functions2009-12-10 05:24:11.0 +0800
 +++ b/rc.d/init.d/functions.new2012-06-01 16:57:12.651229387 +0800
 @@ -16,7 +16,7 @@
-- 
1.7.9.5


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/3] lsbinitscripts: support multilib, link function and add the header for patch

[xiaofeng.yan]

From: Xiaofeng Yan 

Add the multilib support for this package and remove the original 
/etc/init.d/functions and link functions to functions.lsbinitscripts.
Add the header for patch.

The following changes since commit 3f292735407e50eebb23044fa9f579906a94e800:

  gcc-configure-target: Fix sysroot option breakage I introduced (sorry) 
(2012-06-14 19:48:47 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib xiaofeng/lsbinitscripts
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=xiaofeng/lsbinitscripts

Xiaofeng Yan (3):
  multilib.conf: Add the support of multilib for lsbinitscripts
  lsbinitscripts: Remove original /etc/init.d/functions when building
an lsb image
  lsbinitscripts: Add the header for functions.patch

 meta/conf/multilib.conf|1 +
 .../lsb/lsbinitscripts/functions.patch |3 +++
 meta/recipes-extended/lsb/lsbinitscripts_9.03.bb   |8 +++-
 3 files changed, 11 insertions(+), 1 deletion(-)

-- 
1.7.9.5


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/3] lsbinitscripts: Remove original /etc/init.d/functions when building an lsb image

[xiaofeng.yan]

From: Xiaofeng Yan 

The linking will fail when an original functions exist. So remove the
original functions when building an lsb image and make functions linking to
functions.lsbinitscripts successfully.

[YOCTO #2133]

Signed-off-by: Xiaofeng Yan 
---
 meta/recipes-extended/lsb/lsbinitscripts_9.03.bb |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-extended/lsb/lsbinitscripts_9.03.bb 
b/meta/recipes-extended/lsb/lsbinitscripts_9.03.bb
index dd92a92..73bea2f 100644
--- a/meta/recipes-extended/lsb/lsbinitscripts_9.03.bb
+++ b/meta/recipes-extended/lsb/lsbinitscripts_9.03.bb
@@ -2,7 +2,7 @@ DESCRIPTION = "SysV init scripts which only is used in an LSB 
image"
 SECTION = "base"
 LICENSE = "GPLv2"
 DEPENDS = "popt"
-PR = "r0"
+PR = "r1"
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=ebf4e8b49780ab187d51bd26aaa022c6"
 
@@ -25,3 +25,9 @@ do_install(){
install -d ${D}/etc/init.d/
install -m 0755 ${S}/rc.d/init.d/functions ${D}/etc/init.d/functions
 }
+
+pkg_postinst_${PN} () {
+   if [ -f "/etc/init.d/functions" ]; then
+   rm -f /etc/init.d/functions
+   fi
+}
-- 
1.7.9.5


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/3] multilib.conf: Add the support of multilib for lsbinitscripts

[xiaofeng.yan]

From: Xiaofeng Yan 

Add the multilib support for this package to multilib.conf because error will
appear when building an lib32-core-image-lsb without this patch.

[YOCTO #2571]

Signed-off-by: Xiaofeng Yan 
---
 meta/conf/multilib.conf |1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/conf/multilib.conf b/meta/conf/multilib.conf
index 9fc5a90..cea8694 100644
--- a/meta/conf/multilib.conf
+++ b/meta/conf/multilib.conf
@@ -420,6 +420,7 @@ BBCLASSEXTEND_append_pn-lrzsz = " ${MULTILIBS}"
 BBCLASSEXTEND_append_pn-lsb = " ${MULTILIBS}"
 BBCLASSEXTEND_append_pn-lsbsetup = " ${MULTILIBS}"
 BBCLASSEXTEND_append_pn-lsbtest = " ${MULTILIBS}"
+BBCLASSEXTEND_append_pn-lsbinitscripts = " ${MULTILIBS}"
 BBCLASSEXTEND_append_pn-lsof = " ${MULTILIBS}"
 BBCLASSEXTEND_append_pn-ltp = " ${MULTILIBS}"
 BBCLASSEXTEND_append_pn-lttng-control = " ${MULTILIBS}"
-- 
1.7.9.5


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/1] archiver.bbclass: Reduce some duplication for function get_licenses

[xiaofeng.yan]

From: Xiaofeng Yan 

The content to modify this bbclass is as follow:
- Use the existing functions to get license as a directory instead of 
  rewriting it for avoiding code duplication.
- Use SPDXLICENSEMAP to map licenses

The following changes since commit df8f55a919b3cc602ce1f1c51630c7edf6e36b55:
  Cristian Iorga (1):
ltp: Add patch to correct failing build

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib xiaofeng/2473
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=xiaofeng/2473

Xiaofeng Yan (1):
  archiver.bbclass: Reduce some duplication for function get_licenses

 meta/classes/archiver.bbclass |   23 ---
 1 files changed, 12 insertions(+), 11 deletions(-)


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/1] archiver.bbclass: Reduce some duplication for function get_licenses

[xiaofeng.yan]

From: Xiaofeng Yan 

The content to modify this bbclass is as follow:
- Use the existing functions to get license as a directory instead of
  rewriting it for avoiding code duplication.
- Use SPDXLICENSEMAP to map licenses

[YOCTO #2473]

Signed-off-by: Xiaofeng Yan 
---
 meta/classes/archiver.bbclass |   23 ---
 1 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass
index ed2dbe4..083bb1d 100644
--- a/meta/classes/archiver.bbclass
+++ b/meta/classes/archiver.bbclass
@@ -225,17 +225,18 @@ def archive_logs(d,logdir,bbinc=False):
 
 def get_licenses(d):
'''get licenses for running .bb file'''
-   licenses = d.getVar('LICENSE', 1).replace('&', '|')
-   licenses = licenses.replace('(', '').replace(')', '') 
-   clean_licenses = ""
-   for x in licenses.split():
-   if x.strip() == '' or x == 'CLOSED':
-   continue
-   if x != "|":
-   clean_licenses += x
-   if '|' in clean_licenses:
-   clean_licenses = clean_licenses.replace('|','')
-   return clean_licenses
+   import oe.license
+
+   licenses_type = d.getVar('LICENSE', True) or ""
+   lics = oe.license.is_included(licenses_type)[1:][0]
+   lice = ''
+   for lic in lics:
+   licens = d.getVarFlag('SPDXLICENSEMAP', lic)
+   if licens != None:
+   lice += licens
+   else:
+   lice += lic
+   return lice

 
 def move_tarball_deploy(d,tarball_list):
-- 
1.7.0.4


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/3 V2] lsbinitscripts: Add initscripts to enhance init functions in an lsb image

[xiaofeng.yan]

From: Xiaofeng Yan 

The version of initscripts has more functions than the simple.
There could be some errors for current initscripts when running
some programe because of absent some functions provided by initscripts.

[YOCTO #2133]

Signed-off-by: Xiaofeng Yan 
---
 meta/recipes-extended/lsb/lsbinitscripts_9.03.bb |   26 ++
 1 files changed, 26 insertions(+), 0 deletions(-)
 create mode 100644 meta/recipes-extended/lsb/lsbinitscripts_9.03.bb

diff --git a/meta/recipes-extended/lsb/lsbinitscripts_9.03.bb 
b/meta/recipes-extended/lsb/lsbinitscripts_9.03.bb
new file mode 100644
index 000..8ee8636
--- /dev/null
+++ b/meta/recipes-extended/lsb/lsbinitscripts_9.03.bb
@@ -0,0 +1,26 @@
+DESCRIPTION = "SysV init scripts which only is used in an LSB image"
+SECTION = "base"
+LICENSE = "GPLv2"
+PR = "r0"
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=ebf4e8b49780ab187d51bd26aaa022c6"
+
+S="${WORKDIR}/initscripts-${PV}"
+SRC_URI = 
"http://pkgs.fedoraproject.org/repo/pkgs/initscripts/initscripts-${PV}.tar.bz2/668fa2762b57ef75436303857847bba3/initscripts-${PV}.tar.bz2
 \
+   file://functions.patch \
+  " 
+
+SRC_URI[md5sum] = "668fa2762b57ef75436303857847bba3"
+SRC_URI[sha256sum] = 
"d56547a68ce223a7413b2676650b042125f047c8d6d139c5b970e118b3dc958a"
+inherit update-alternatives
+
+ALTERNATIVE_PRIORITY = "10"
+ALTERNATIVE_${PN} = "functions"
+ALTERNATIVE_LINK_NAME[functions] = "${sysconfdir}/init.d/functions"
+
+do_configure[noexec] = "1" 
+
+do_install(){
+   install -d ${D}/etc/init.d/
+   install -m 0755 ${S}/rc.d/init.d/functions ${D}/etc/init.d/functions
+}
-- 
1.7.0.4


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/3 V2]lsb: Add initscripts to enhance init functions in an lsb image

[xiaofeng.yan]

From: Xiaofeng Yan 

This is V2. The modification is as follows by comparison with V1:
- Add extra description in section "DESCRIPTION"
- Use bbclass update-alternatives instead of command method.

The following changes since commit de4cdfd6bc1280ac7ac0559b87734d26294ef773:
  Scott Rifenbark (1):
documentation/kernel-manual/kernel-how-to.xml: Updated to kernel 3.4

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib xiaofeng/2133
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=xiaofeng/2133

Xiaofeng Yan (3):
  lsbinitscripts: Add initscripts to enhance init functions in an lsb
image
  lsbinitscripts: Patch file functions for confirming to an lsb image
  task-core-lsb: Add another initscripts to an lsb image

 .../lsb/lsbinitscripts/functions.patch |   11 
 meta/recipes-extended/lsb/lsbinitscripts_9.03.bb   |   26 
 meta/recipes-extended/tasks/task-core-lsb.bb   |3 +-
 3 files changed, 39 insertions(+), 1 deletions(-)
 create mode 100644 meta/recipes-extended/lsb/lsbinitscripts/functions.patch
 create mode 100644 meta/recipes-extended/lsb/lsbinitscripts_9.03.bb


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/3 V2] lsbinitscripts: Patch file functions for confirming to an lsb image

[xiaofeng.yan]

From: Xiaofeng Yan 

Add the condition judgment to functions for avoiding to print error
information when system start up at first.

[YOCTO #2133]

Signed-off-by: Xiaofeng Yan 
---
 .../lsb/lsbinitscripts/functions.patch |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)
 create mode 100644 meta/recipes-extended/lsb/lsbinitscripts/functions.patch

diff --git a/meta/recipes-extended/lsb/lsbinitscripts/functions.patch 
b/meta/recipes-extended/lsb/lsbinitscripts/functions.patch
new file mode 100644
index 000..aa63cec
--- /dev/null
+++ b/meta/recipes-extended/lsb/lsbinitscripts/functions.patch
@@ -0,0 +1,11 @@
+--- a/rc.d/init.d/functions2009-12-10 05:24:11.0 +0800
 b/rc.d/init.d/functions.new2012-06-01 16:57:12.651229387 +0800
+@@ -16,7 +16,7 @@
+ # Get a sane screen width
+ [ -z "${COLUMNS:-}" ] && COLUMNS=80
+ 
+-[ -z "${CONSOLETYPE:-}" ] && CONSOLETYPE="$(/sbin/consoletype)"
++[ -z "${CONSOLETYPE:-}" ] && [ -e /sbin/consoletype ] && 
CONSOLETYPE="$(/sbin/consoletype)"
+ 
+ if [ -f /etc/sysconfig/i18n -a -z "${NOLOCALE:-}" -a -z "${LANGSH_SOURCED:-}" 
] ; then
+   . /etc/profile.d/lang.sh 2>/dev/null
-- 
1.7.0.4


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 3/3 V2] task-core-lsb: Add another initscripts to an lsb image

[xiaofeng.yan]

From: Xiaofeng Yan 

Initscripts with stronger functions will replace the simple one,
which will avoid error when some packages need functions which could
be absent in the simple initscripts.

[YOCTO #2133]

Signed-off-by: Xiaofeng Yan 
---
 meta/recipes-extended/tasks/task-core-lsb.bb |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/meta/recipes-extended/tasks/task-core-lsb.bb 
b/meta/recipes-extended/tasks/task-core-lsb.bb
index 99ca839..4faf4d7 100644
--- a/meta/recipes-extended/tasks/task-core-lsb.bb
+++ b/meta/recipes-extended/tasks/task-core-lsb.bb
@@ -3,7 +3,7 @@
 #
 
 DESCRIPTION = "Create Small Image Tasks"
-PR = "r8"
+PR = "r9"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = 
"file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
 
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
@@ -80,6 +80,7 @@ RDEPENDS_task-core-sys-extended = "\
 which \
 xinetd \
 zip \
+lsbinitscripts \
 "
 
 RDEPENDS_task-core-db = "\
-- 
1.7.0.4


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/2] local.conf.sample.extended: Change the usage about arhiver.bbclass

[xiaofeng.yan]

From: Xiaofeng Yan 

Change the usage about arhiver.bbclass due to the improvement for
usability of archiver.bbclass

[YOCTO #2472]

Signed-off-by: Xiaofeng Yan 
---
 meta-yocto/conf/local.conf.sample.extended |   31 ---
 1 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/meta-yocto/conf/local.conf.sample.extended 
b/meta-yocto/conf/local.conf.sample.extended
index b493094..66b94ad 100644
--- a/meta-yocto/conf/local.conf.sample.extended
+++ b/meta-yocto/conf/local.conf.sample.extended
@@ -184,20 +184,25 @@
 
 # Archiving source code configuration
 #
-# The following variables control which files to archive and the type to 
archive to generate.
-# There are three basic class defintions of common operations that might be 
desired and these
-# can be enabled by uncommenting one of the following lines:
-#
-# INHERIT += "archive-original-source"
-# INHERIT += "archive-patched-source"
-#INHERIT =+ "archive-configured-source"
-#
+# The following variables control which files to archive and
+# the type to archive to generate.
+# The content to archive
+# "original":Copy source code package from downloads if existing. 
+# Archive source code after do_unpack if not found in downloads 
+# "patched":Archive source code package after do_patch
+# "configured": Archive source code package after do_configure 
+# ARCHIVER_MODE[choices] = "none original patched configured"
 # Type of archive:
-# SOURCE_ARCHIVE_PACKAGE_TYPE = 'srpm'
-#SOURCE_ARCHIVE_PACKAGE_TYPE ?= 'tar'
-#
+# ARCHIVER_MODE[type] = "tar srpm"
 # Whether to include WORKDIR/temp, .bb and .inc files:
 # 'logs_with_scripts' include WORKDIR/temp directory and .bb and .inc files
 # 'logs' only include WORKDIR/temp
-# SOURCE_ARCHIVE_LOG_WITH_SCRIPTS ?= 'logs'
-#SOURCE_ARCHIVE_LOG_WITH_SCRIPTS ?= 'logs_with_scripts'
+# ARCHIVER_MODE[log_type] = "logs logs_with_scripts"
+# There are three basic class defintions of common operations 
+# that might be desired and these can be enabled by 
+# uncommenting five of the following lines:
+#ARCHIVER_MODE ?= "original"
+#ARCHIVER_MODE[type] ?= "tar"
+#ARCHIVER_MODE[log_type] ?= "logs_with_scripts"
+#ARCHIVER_CLASS = "${@'archive-${ARCHIVER_MODE}-source' if ARCHIVER_MODE != 
'none' else ''}"
+#INHERIT += "${ARCHIVER_CLASS}"
-- 
1.7.0.4


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/2] archiver.bbclass:Improve the usability for the archiver classes

[xiaofeng.yan]

From: Xiaofeng Yan 

The usability of the archiver classes can be improved, beyond the 
simple addition of default values for the variables. 
A user could well inherit just archiver rather than the individual 
useful classes, and not realize it will do nothing.

The following changes since commit f28209d9d3c67203a2c7a2b25cacfe31643d1bfa:
  Kang Kai (1):
cooker.py: terminate the Parser processes

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib xiaofeng/2472
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=xiaofeng/2472

Xiaofeng Yan (2):
  archiver.bbclass: Improve the usability for the archiver classes
  local.conf.sample.extended: Change the usage about arhiver.bbclass

 meta-yocto/conf/local.conf.sample.extended |   31 ---
 meta/classes/archiver.bbclass  |6 +++-
 2 files changed, 22 insertions(+), 15 deletions(-)


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/2] archiver.bbclass: Improve the usability for the archiver classes

[xiaofeng.yan]

From: Xiaofeng Yan 

The usability of the archiver classes can be improved, beyond the
simple addition of default values for the variables. A user could
well inherit just archiver rather than the individual useful classes,
and not realize it will do nothing.

[YOCTO #2472]

Signed-off-by: Xiaofeng Yan 
---
 meta/classes/archiver.bbclass |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass
index ac8aa95..582c565 100644
--- a/meta/classes/archiver.bbclass
+++ b/meta/classes/archiver.bbclass
@@ -6,8 +6,10 @@ ARCHIVE_EXCLUDE_FROM ?= ".pc autom4te.cache"
 ARCHIVE_TYPE ?= "TAR SRPM"
 DISTRO ?= "poky"
 PATCHES_ARCHIVE_WITH_SERIES = 'TRUE'
-SOURCE_ARCHIVE_LOG_WITH_SCRIPTS ?= 'logs_with_scripts'
-SOURCE_ARCHIVE_PACKAGE_TYPE ?= 'tar'
+SOURCE_ARCHIVE_LOG_WITH_SCRIPTS ?= '${@d.getVarFlag('ARCHIVER_MODE', 
'log_type') \
+if d.getVarFlag('ARCHIVER_MODE', 
'log_type') != 'none' else 'logs_with_scripts'}'
+SOURCE_ARCHIVE_PACKAGE_TYPE ?= '${@d.getVarFlag('ARCHIVER_MODE','type') \
+ if d.getVarFlag('ARCHIVER_MODE', 
'log_type')!= 'none' else 'tar'}'
 
 def get_bb_inc(d):
'''create a directory "script-logs" including .bb and .inc file in 
${WORKDIR}'''
-- 
1.7.0.4


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/3] lsbinitscripts: Patch file functions for confirming to an lsb image

[xiaofeng.yan]

From: Xiaofeng Yan 

Add the condition judgment to functions for avoiding to print error \
information when system start up at first.

[YOCTO #2133]

Signed-off-by: Xiaofeng Yan 
---
 .../lsb/lsbinitscripts/functions.patch |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)
 create mode 100644 meta/recipes-extended/lsb/lsbinitscripts/functions.patch

diff --git a/meta/recipes-extended/lsb/lsbinitscripts/functions.patch 
b/meta/recipes-extended/lsb/lsbinitscripts/functions.patch
new file mode 100644
index 000..1906b27
--- /dev/null
+++ b/meta/recipes-extended/lsb/lsbinitscripts/functions.patch
@@ -0,0 +1,14 @@
+Upstream-Status: Inappropriate [embedded specific]
+Signed-off-by: Xiaofeng Yan 
+--- a/rc.d/init.d/functions2009-12-10 05:24:11.0 +0800
 b/rc.d/init.d/functions.new2012-05-29 14:48:53.900229435 +0800
+@@ -16,7 +16,8 @@
+ # Get a sane screen width
+ [ -z "${COLUMNS:-}" ] && COLUMNS=80
+ 
+-[ -z "${CONSOLETYPE:-}" ] && CONSOLETYPE="$(/sbin/consoletype)"
++
++[ -z "${CONSOLETYPE:-}" ] && [ -e /sbin/consoletype ] && 
CONSOLETYPE="$(/sbin/consoletype)"
+ 
+ if [ -f /etc/sysconfig/i18n -a -z "${NOLOCALE:-}" -a -z "${LANGSH_SOURCED:-}" 
] ; then
+   . /etc/profile.d/lang.sh 2>/dev/null
-- 
1.7.0.4


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/3 V1]:lsb: Add initscripts to enhance init functions in an lsb image

[xiaofeng.yan]

From: Xiaofeng Yan 

This initscripts has more functions than the simple one. There could be some 
errors for the current version with simple functions when running some programs 
because of absent some functions provided by initscripts.

The following changes since commit f28209d9d3c67203a2c7a2b25cacfe31643d1bfa:
  Kang Kai (1):
cooker.py: terminate the Parser processes

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib xiaofeng/2133
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=xiaofeng/2133

Xiaofeng Yan (3):
  lsbinitscripts: Add initscripts to enhance init functions in an lsb
image
  lsbinitscripts: Patch file functions for confirming to an lsb image
  task-core-lsb: Add another initscripts to an lsb image

 .../lsb/lsbinitscripts/functions.patch |   14 
 meta/recipes-extended/lsb/lsbinitscripts_9.03.bb   |   36 
 meta/recipes-extended/tasks/task-core-lsb.bb   |3 +-
 3 files changed, 52 insertions(+), 1 deletions(-)
 create mode 100644 meta/recipes-extended/lsb/lsbinitscripts/functions.patch
 create mode 100644 meta/recipes-extended/lsb/lsbinitscripts_9.03.bb


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/3] lsbinitscripts: Add initscripts to enhance init functions in an lsb image

[xiaofeng.yan]

From: Xiaofeng Yan 

The version of initscripts has more functions than the simple. \
There could be some errors for current initscripts when running \
some programe because of absent some functions provided by \
initscripts.

[YOCTO #2133]

Signed-off-by: Xiaofeng Yan 
---
 meta/recipes-extended/lsb/lsbinitscripts_9.03.bb |   36 ++
 1 files changed, 36 insertions(+), 0 deletions(-)
 create mode 100644 meta/recipes-extended/lsb/lsbinitscripts_9.03.bb

diff --git a/meta/recipes-extended/lsb/lsbinitscripts_9.03.bb 
b/meta/recipes-extended/lsb/lsbinitscripts_9.03.bb
new file mode 100644
index 000..5d2bca8
--- /dev/null
+++ b/meta/recipes-extended/lsb/lsbinitscripts_9.03.bb
@@ -0,0 +1,36 @@
+DESCRIPTION = "SysV init scripts"
+SECTION = "base"
+LICENSE = "GPLv2"
+PR = "r0"
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=ebf4e8b49780ab187d51bd26aaa022c6"
+
+S="${WORKDIR}/initscripts-${PV}"
+SRC_URI = 
"http://pkgs.fedoraproject.org/repo/pkgs/initscripts/initscripts-${PV}.tar.bz2/668fa2762b57ef75436303857847bba3/initscripts-${PV}.tar.bz2
 \
+   file://functions.patch \
+  " 
+
+SRC_URI[md5sum] = "668fa2762b57ef75436303857847bba3"
+SRC_URI[sha256sum] = 
"d56547a68ce223a7413b2676650b042125f047c8d6d139c5b970e118b3dc958a"
+
+do_configure[noexec] = "1" 
+
+do_install(){
+   install -d ${D}/etc/init.d/
+   install -m 0755 ${S}/rc.d/init.d/functions ${D}/etc/init.d/functions
+if [ "${PN}" = "lsbinitscripts" ]; then
+   mv ${D}${sysconfdir}/init.d/functions 
${D}${sysconfdir}/init.d/functions.${PN}
+   fi
+}
+
+pkg_postinst_${PN}(){
+if [ "${PN}" = "lsbinitscripts" ]; then
+   update-alternatives --install  ${sysconfdir}/init.d/functions 
functions functions.${PN} 10
+   fi
+}
+
+pkg_prerm_${PN}(){
+if [ "${PN}" = "lsbinitscripts" ]; then
+   update-alternatives --remove functions  
${sysconfdir}/init.d/functions.${PN}
+   fi
+}
-- 
1.7.0.4


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 3/3] task-core-lsb: Add another initscripts to an lsb image

[xiaofeng.yan]

From: Xiaofeng Yan 

Initscripts with stronger functions will replace the simple one, \
which will avoid error when some packages need functions which could \
be absent in the simple initscripts.

[YOCTO #2133]

Signed-off-by: Xiaofeng Yan 
---
 meta/recipes-extended/tasks/task-core-lsb.bb |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/meta/recipes-extended/tasks/task-core-lsb.bb 
b/meta/recipes-extended/tasks/task-core-lsb.bb
index 99ca839..c8db300 100644
--- a/meta/recipes-extended/tasks/task-core-lsb.bb
+++ b/meta/recipes-extended/tasks/task-core-lsb.bb
@@ -3,7 +3,7 @@
 #
 
 DESCRIPTION = "Create Small Image Tasks"
-PR = "r8"
+PR = "r9"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = 
"file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \
 
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
@@ -80,6 +80,7 @@ RDEPENDS_task-core-sys-extended = "\
 which \
 xinetd \
 zip \
+lsbinitscripts\
 "
 
 RDEPENDS_task-core-db = "\
-- 
1.7.0.4


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/1] ncurses: Avoid occasional builling failure when having parallel processable task

[xiaofeng.yan]

From: Xiaofeng Yan 

ncurses failure non-gplv3 build (race issue) like the following \
error information:

| tic: error while loading shared libraries: /srv/home/pokybuild \
/yocto-autobuilder/yocto-slave/nightly-non-gpl3/build/build/tmp/\
work/x86_64-linux/ncurses-native-5.9-r8.1/ncurses-5.9/narrowc/lib\
/libtinfo.so.5: file too short
| ? tic could not build /srv/home/pokybuild/yocto-autobuilder/\
yocto-slave/nightly-non-gpl3/build/build/tmp/work/x86_64-linux/\
ncurses-native-5.9-r8.1/image/srv/home/pokybuild/yocto-autobuilder\
/yocto-slave/nightly-non-gpl3/build/build/tmp/sysroots/x86_64-linux\
/usr/share/terminfo
| make[1]: *** [install.data] Error 1

This is a race issue which is caused by
install.libs and install.data:

1) install.data needs run tic
2) tic needs libtinfo.so
3) install.libs would regenerate libtinfo.so
4) but install.data doesn't depend on install.libs, and they can run
   parallelly

So there would be errors in a very critical condition: tic is begining
to run at the same time when install.libs is generating libtinfo.so, and
this libtinfo.so is not integrity, then there would be the  above error.

Let task install.libs run before install.data for fixing this bug.

[YOCTO #2298]

Signed-off-by: Xiaofeng Yan 
---
 meta/recipes-core/ncurses/ncurses.inc |   23 ++-
 1 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-core/ncurses/ncurses.inc 
b/meta/recipes-core/ncurses/ncurses.inc
index ae99e2c..b031119 100644
--- a/meta/recipes-core/ncurses/ncurses.inc
+++ b/meta/recipes-core/ncurses/ncurses.inc
@@ -6,7 +6,7 @@ LIC_FILES_CHKSUM = 
"file://ncurses/base/version.c;beginline=1;endline=27;md5=cbc
 SECTION = "libs"
 DEPENDS = "ncurses-native"
 DEPENDS_virtclass-native = ""
-INC_PR = "r8"
+INC_PR = "r9"
 
 inherit autotools binconfig multilib_header
 
@@ -107,10 +107,15 @@ do_test() {
 diff curses-narrowc.h curses-widec.h
 }
 
+# Split original _install_opts to two parts.
+# One is the options to install contents, the other is the parameters \
+# when running command "make install"
 _install_opts = "\
+  install.libs install.includes install.man \
+"
+_install_cfgs = "\
   DESTDIR='${D}' \
   PKG_CONFIG_LIBDIR='${libdir}/pkgconfig' \
-  install.libs install.includes install.man \
 "
 
 python do_install () {
@@ -122,11 +127,19 @@ shell_do_install() {
 # Order of installation is important; widec installs a 'curses.h'
 # header with more definitions and must be installed last hence.
 # Compatibility of these headers will be checked in 'do_test()'.
-oe_runmake -C narrowc ${_install_opts} \
-install.data install.progs
+oe_runmake -C narrowc ${_install_cfgs} ${_install_opts} \
+install.progs
+
+# The install.data should run after install.libs, otherwise
+# there would be a race issue in a very critical conditon, since
+# tic will be run by install.data, and tic needs libtinfo.so
+# which would be regenerated by install.libs.
+oe_runmake -C narrowc ${_install_cfgs} \
+install.data
+
 
 ! ${ENABLE_WIDEC} || \
-oe_runmake -C widec ${_install_opts}
+oe_runmake -C widec ${_install_cfgs} ${_install_opts}
 
 cd narrowc
 
-- 
1.7.0.4


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/1] ncurses: Avoid occasional builling failure when having parallel processable task

[xiaofeng.yan]

From: Xiaofeng Yan 

| tic: error while loading shared libraries: /srv/home/pokybuild \
/yocto-autobuilder/yocto-slave/nightly-non-gpl3/build/build/tmp/\
work/x86_64-linux/ncurses-native-5.9-r8.1/ncurses-5.9/narrowc/lib\
/libtinfo.so.5: file too short
| ? tic could not build /srv/home/pokybuild/yocto-autobuilder/\
yocto-slave/nightly-non-gpl3/build/build/tmp/work/x86_64-linux/\
ncurses-native-5.9-r8.1/image/srv/home/pokybuild/yocto-autobuilder\
/yocto-slave/nightly-non-gpl3/build/build/tmp/sysroots/x86_64-linux\
/usr/share/terminfo
| make[1]: *** [install.data] Error 1

This is a race issue which is caused by
install.libs and install.data:

1) install.data needs run tic
2) tic needs libtinfo.so
3) install.libs would regenerate libtinfo.so
4) but install.data doesn't depend on install.libs, and they can run
   parallelly

So there would be errors in a very critical condition: tic is begining
to run at the same time when install.libs is generating libtinfo.so, and
this libtinfo.so is not integrity, then there would be the  above error.

Let task install.libs run before install.data for fixing this bug.

The following changes since commit b4c8c74a45e386f99344cf9799eb5294ad6c9e3e:
  Joshua Lock (1):
hob: update required pygtk to 2.22.0 and gtk+ to 2.20.0

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib xiaofeng/2298
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=xiaofeng/2298

Xiaofeng Yan (1):
  ncurses: Avoid occasional builling failure when having parallel
processable task

 meta/recipes-core/ncurses/ncurses.inc |   23 ++-
 1 files changed, 18 insertions(+), 5 deletions(-)


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/1] ncurses: Disable parallel make

[xiaofeng.yan]

From: Xiaofeng Yan 

I can't reproduce bug 2298 after building ncurses successfully many time 
because Richard said "Its a race issue and sometimes occurs with high values of 
PARALLEL_MAKE. This means it will sometimes appear and sometimes not appear". I 
didn't know whether this patch is appropriate or not? I will appreciate him 
very much if anyone has the resolution.

The following changes since commit d4e265661517f8dd4e1648fdc56bac5973f986f6:
  Saul Wold (1):
poky.conf: Change WARNS -> ERRORS

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib xiaofeng/2298
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=xiaofeng/2298

Xiaofeng Yan (1):
  ncurses: Disable parallel make

 meta/recipes-core/ncurses/ncurses.inc |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/1] ncurses: Disable parallel make

[xiaofeng.yan]

From: Xiaofeng Yan 

Ncurses failure non-gplv3 build by race issue. So disable parallel \
make when building this package.

Signed-off-by: Xiaofeng Yan 
---
 meta/recipes-core/ncurses/ncurses.inc |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/meta/recipes-core/ncurses/ncurses.inc 
b/meta/recipes-core/ncurses/ncurses.inc
index ae99e2c..b115e46 100644
--- a/meta/recipes-core/ncurses/ncurses.inc
+++ b/meta/recipes-core/ncurses/ncurses.inc
@@ -29,6 +29,8 @@ BUILD_CPPFLAGS += "-D_GNU_SOURCE"
 # natives don't generally look in base_libdir
 base_libdir_virtclass-native = "${libdir}"
 
+PARALLEL_MAKE = ""
+
 # Helper function for do_configure to allow multiple configurations
 # $1 the directory to run configure in
 # $@ the arguments to pass to configure
-- 
1.7.0.4


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/1] archiver.bbclass: Add two default set for avoiding error when missing assignment

[xiaofeng.yan]

From: Xiaofeng Yan 

Add two default set(SOURCE_ARCHIVE_LOG_WITH_SCRIPTS, \
SOURCE_ARCHIVE_PACKAGE_TYPE) to archiver.bbclass for avoiding \
building error when forgetting to assign to them.

Signed-off-by: Xiaofeng Yan 
---
 meta/classes/archiver.bbclass |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass
index 59b58f4..ac8aa95 100644
--- a/meta/classes/archiver.bbclass
+++ b/meta/classes/archiver.bbclass
@@ -6,6 +6,8 @@ ARCHIVE_EXCLUDE_FROM ?= ".pc autom4te.cache"
 ARCHIVE_TYPE ?= "TAR SRPM"
 DISTRO ?= "poky"
 PATCHES_ARCHIVE_WITH_SERIES = 'TRUE'
+SOURCE_ARCHIVE_LOG_WITH_SCRIPTS ?= 'logs_with_scripts'
+SOURCE_ARCHIVE_PACKAGE_TYPE ?= 'tar'
 
 def get_bb_inc(d):
'''create a directory "script-logs" including .bb and .inc file in 
${WORKDIR}'''
@@ -277,7 +279,7 @@ def get_package(d):
try:
f = open(tarpackage,'r')
line = list(set(f.readline().replace('\n','').split()))
-   except IOError:
+   except UnboundLocalError,IOError:
pass
f.close()
return line
-- 
1.7.0.4


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/1] archiver.bbclass: Add two default set for avoiding error when missing assignment

[xiaofeng.yan]

From: Xiaofeng Yan 

This is V2.

Add two default set(SOURCE_ARCHIVE_LOG_WITH_SCRIPTS, 
SOURCE_ARCHIVE_PACKAGE_TYPE) to archiver.bbclass for avoiding building error 
when forgetting to assign to them.
Make some modification according to clarson's suggestion. Thank him correct my 
fault.

The following changes since commit d4e265661517f8dd4e1648fdc56bac5973f986f6:
  Saul Wold (1):
poky.conf: Change WARNS -> ERRORS

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib xiaofeng/archiver
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=xiaofeng/archiver

Xiaofeng Yan (1):
  archiver.bbclass: Add two default set for avoiding error when missing
assignment

 meta/classes/archiver.bbclass |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/1] archiver.bbclass: Add two default set for avoiding error when missing assignment

[xiaofeng.yan]

From: Xiaofeng Yan 

Add two default set(SOURCE_ARCHIVE_LOG_WITH_SCRIPTS, 
SOURCE_ARCHIVE_PACKAGE_TYPE) to archiver.bbclass for avoiding building error 
when forgetting to assign to them.

Pull URL: git://git.pokylinux.org/poky-contrib.git
  Branch: xiaofeng/archiver
  Browse: 
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=xiaofeng/archiver

Thanks,
Xiaofeng Yan 
---


Xiaofeng Yan (1):
  archiver.bbclass: Add default set

 meta/classes/archiver.bbclass |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/1] archiver.bbclass: Add default set

[xiaofeng.yan]

From: Xiaofeng Yan 

Add two default set(SOURCE_ARCHIVE_LOG_WITH_SCRIPTS, \
SOURCE_ARCHIVE_PACKAGE_TYPE) to archiver.bbclass for avoiding \
building error when forgetting to assign to them.

Signed-off-by: Xiaofeng Yan 
---
 meta/classes/archiver.bbclass |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass
index 59b58f4..a720db2 100644
--- a/meta/classes/archiver.bbclass
+++ b/meta/classes/archiver.bbclass
@@ -6,6 +6,10 @@ ARCHIVE_EXCLUDE_FROM ?= ".pc autom4te.cache"
 ARCHIVE_TYPE ?= "TAR SRPM"
 DISTRO ?= "poky"
 PATCHES_ARCHIVE_WITH_SERIES = 'TRUE'
+SOURCE_ARCHIVE_LOG_WITH_SCRIPTS ?= 'logs_with_scripts'
+SOURCE_ARCHIVE_PACKAGE_TYPE ?= 'tar'
+export SOURCE_ARCHIVE_LOG_WITH_SCRIPTS
+export SOURCE_ARCHIVE_PACKAGE_TYPE
 
 def get_bb_inc(d):
'''create a directory "script-logs" including .bb and .inc file in 
${WORKDIR}'''
@@ -277,7 +281,7 @@ def get_package(d):
try:
f = open(tarpackage,'r')
line = list(set(f.readline().replace('\n','').split()))
-   except IOError:
+   except UnboundLocalError,IOError:
pass
f.close()
return line
-- 
1.7.0.4


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core