The architecture specific information of the running processes could
be useful to the userland. Add support to examine process architecture
specific information externally.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
---
fs
1.004031387 seconds time elapsed
Non-zero counter value confirms that the task causes frequency drop.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
---
arch/x86/include/asm/processor.h | 2 ++
arch/x86/kernel/fpu/xstate.c | 41
Commit-ID: 2f7726f955572e587d5f50fbe9b2deed5334bd90
Gitweb: https://git.kernel.org/tip/2f7726f955572e587d5f50fbe9b2deed5334bd90
Author: Aubrey Li
AuthorDate: Fri, 18 Jan 2019 02:38:20 +0800
Committer: Ingo Molnar
CommitDate: Mon, 11 Feb 2019 14:28:56 +0100
x86/fpu: Track AVX-512 usage
.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
---
arch/x86/include/asm/fpu/internal.h | 7 +++
arch/x86/include/asm/fpu/types.h| 7 +++
2 files changed, 14 insertions(+)
diff --git a/arch/x86/include/asm/fpu/internal.h
b
1.004031387 seconds time elapsed
Non-zero counter value confirms that the task causes frequency drop.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
---
arch/x86/kernel/fpu/xstate.c | 38
fs/proc
Added AVX512_elapsed_ms in /proc//status. Report it
in Documentation/filesystems/proc.txt
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
---
Documentation/filesystems/proc.txt | 4 +++-
1 file changed, 3 insertions(+), 1
.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
---
arch/x86/include/asm/fpu/internal.h | 7 +++
arch/x86/include/asm/fpu/types.h| 7 +++
2 files changed, 14 insertions(+)
diff --git a/arch/x86/include/asm/fpu/internal.h
b
Added AVX512_elapsed_ms in /proc//status. Report it
in Documentation/filesystems/proc.txt
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
---
Documentation/filesystems/proc.txt | 4 +++-
1 file changed, 3 insertions(+), 1
1.004031387 seconds time elapsed
Non-zero counter value confirms that the task causes frequency drop.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
---
arch/x86/kernel/fpu/xstate.c | 38
fs/proc
1.004031387 seconds time elapsed
Non-zero counter value confirms that the task causes frequency drop.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
---
arch/x86/kernel/fpu/xstate.c | 34 ++
fs/proc
.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
---
arch/x86/include/asm/fpu/internal.h | 7 +++
arch/x86/include/asm/fpu/types.h| 7 +++
2 files changed, 14 insertions(+)
diff --git a/arch/x86/include/asm/fpu/internal.h
b
Added AVX512_elapsed_ms in /proc//status. Report it
in Documentation/filesystems/proc.txt
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
---
Documentation/filesystems/proc.txt | 4 +++-
1 file changed, 3 insertions(+), 1
Added AVX512_elapsed_ms in /proc//status. Report it
in Documentation/filesystems/proc.txt
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
---
Documentation/filesystems/proc.txt | 4 +++-
1 file changed, 3 insertions(+), 1
1.004031387 seconds time elapsed
Non-zero counter value confirms that the task causes frequency drop.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
---
arch/x86/kernel/fpu/xstate.c | 34 ++
fs/proc
.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
---
arch/x86/include/asm/fpu/internal.h | 7 +++
arch/x86/include/asm/fpu/types.h| 7 +++
2 files changed, 14 insertions(+)
diff --git a/arch/x86/include/asm/fpu/internal.h
b
.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
---
arch/x86/include/asm/fpu/internal.h | 7 +++
arch/x86/include/asm/fpu/types.h| 7 +++
2 files changed, 14 insertions(+)
diff --git a/arch/x86/include/asm/fpu/internal.h
b
1.004031387 seconds time elapsed
Non-zero counter value confirms that the task causes frequency drop.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
---
arch/x86/kernel/fpu/xstate.c | 34 ++
fs/proc
Added AVX512_elapsed_ms in /proc//status. Report it
in Documentation/filesystems/proc.txt
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
---
Documentation/filesystems/proc.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git
core_power.lvl2_turbo_license -- sleep 1
Performance counter stats for process id '3558':
3,251,565,961 core_power.lvl2_turbo_license
1.004031387 seconds time elapsed
Non-zero counter value confirms that the task causes frequency drop.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
real-world workloads like tensorflow and linpack.
If higher precision is required, suggest user space tools to use the
PMU-based mechanisms in combination.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van de Ven
---
arch/x86/include/asm
Add a /proc//arch_state interface to expose per-task cpu specific
state values.
Exposing AVX-512 Hi16_ZMM registers usage is for the user space job
scheduler to cluster AVX-512 using tasks together, because these tasks
could cause core turbo frequency drop.
Signed-off-by: Aubrey Li
Cc: Peter
immediately, but requires 3
consecutive context switches with no usage to clear it. This decay is
required because of AVX-512 using tasks could set Hi16_ZMM state back
to the init state themselves.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van
immediately, but requires 3
consecutive context switches with no usage to clear it. This decay is
required because of AVX-512 using tasks could set Hi16_ZMM state back
to the init state themselves.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Dave Hansen
Cc: Arjan van
Add a /proc//arch_state interface to expose per-task cpu specific
state values.
Exposing AVX-512 Hi16_ZMM registers usage is for the user space job
scheduler to cluster AVX-512 using tasks together, because these tasks
could cause core turbo frequency drop.
Signed-off-by: Aubrey Li
Cc: Peter
Expose the per-task cpu specific thread state value, it's helpful
for userland to classify and schedule the tasks by different policies
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Arjan van de Ven
---
arch/x86/kernel/fpu/xstate.c | 13 +
fs/proc
Expose the per-task cpu specific thread state value, it's helpful
for userland to classify and schedule the tasks by different policies
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Arjan van de Ven
---
arch/x86/kernel/fpu/xstate.c | 13 +
fs/proc
.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Arjan van de Ven
---
arch/x86/include/asm/fpu/internal.h | 97 +++--
arch/x86/include/asm/fpu/types.h| 17 +++
2 files changed, 88 insertions(+), 26 deletions(-)
diff --git
.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Arjan van de Ven
---
arch/x86/include/asm/fpu/internal.h | 97 +++--
arch/x86/include/asm/fpu/types.h| 17 +++
2 files changed, 88 insertions(+), 26 deletions(-)
diff --git
Expose the per-task cpu specific thread state value, it's helpful
for userland to classify and schedule the tasks by different policies
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Arjan van de Ven
---
arch/x86/kernel/fpu/xstate.c | 13 +
fs/proc
Expose the per-task cpu specific thread state value, it's helpful
for userland to classify and schedule the tasks by different policies
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Arjan van de Ven
---
arch/x86/kernel/fpu/xstate.c | 13 +
fs/proc
.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Arjan van de Ven
---
arch/x86/include/asm/fpu/internal.h | 97 +++--
arch/x86/include/asm/fpu/types.h| 17 +++
2 files changed, 88 insertions(+), 26 deletions(-)
diff --git
.
Signed-off-by: Aubrey Li
Cc: Peter Zijlstra
Cc: Andi Kleen
Cc: Tim Chen
Cc: Arjan van de Ven
---
arch/x86/include/asm/fpu/internal.h | 97 +++--
arch/x86/include/asm/fpu/types.h| 17 +++
2 files changed, 88 insertions(+), 26 deletions(-)
diff --git
be done according to the same indicator.
I observed when system is idle, the idle predictor reports 20/s long idle
and ZERO fast idle on one CPU. And when the workload is running, the idle
predictor reports 72899/s fast idle and ZERO long idle on the same CPU.
Aubrey Li (8):
cpuidle: menu: extract
be done according to the same indicator.
I observed when system is idle, the idle predictor reports 20/s long idle
and ZERO fast idle on one CPU. And when the workload is running, the idle
predictor reports 72899/s fast idle and ZERO long idle on the same CPU.
Aubrey Li (8):
cpuidle: menu: extract
If the next idle is expected to be a fast idle, we should keep tick
on before going into idle
Signed-off-by: Aubrey Li <aubrey...@linux.intel.com>
---
drivers/cpuidle/cpuidle.c | 14 ++
include/linux/cpuidle.h | 2 ++
kernel/time/tick-sched.c | 4
3 files chang
If the next idle is expected to be a fast idle, we should keep tick
on before going into idle
Signed-off-by: Aubrey Li
---
drivers/cpuidle/cpuidle.c | 14 ++
include/linux/cpuidle.h | 2 ++
kernel/time/tick-sched.c | 4
3 files changed, 20 insertions(+)
diff --git
sleep length indicates how long we'll be idle. Currently, it's updated
only when tick nohz enters. These patch series make a new requirement
with tick, so we should keep sleep length updated as needed
---
kernel/time/tick-sched.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
There are several factors in the menu governor to predict the next
idle interval:
- the next timer
- the recent idle interval history
- the corrected idle interval pattern
These factors are common enough to be extracted to be one function.
Signed-off-by: Aubrey Li <aubrey...@linux.intel.
sleep length indicates how long we'll be idle. Currently, it's updated
only when tick nohz enters. These patch series make a new requirement
with tick, so we should keep sleep length updated as needed
---
kernel/time/tick-sched.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
There are several factors in the menu governor to predict the next
idle interval:
- the next timer
- the recent idle interval history
- the corrected idle interval pattern
These factors are common enough to be extracted to be one function.
Signed-off-by: Aubrey Li
---
drivers/cpuidle/governors
Add a knob to make fast idle threshold tunable
Signed-off-by: Aubrey Li <aubrey...@linux.intel.com>
---
drivers/cpuidle/cpuidle.c | 3 ++-
include/linux/cpuidle.h | 1 +
kernel/sysctl.c | 12
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/d
Add a knob to make fast idle threshold tunable
Signed-off-by: Aubrey Li
---
drivers/cpuidle/cpuidle.c | 3 ++-
include/linux/cpuidle.h | 1 +
kernel/sysctl.c | 12
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers
Record the overhead of idle entry in micro-second
Signed-off-by: Aubrey Li <aubrey...@linux.intel.com>
---
drivers/cpuidle/cpuidle.c | 33 +
include/linux/cpuidle.h | 14 ++
kernel/sched/idle.c | 8 +++-
3 files changed, 54 inse
Introduce irq timings output as a factor to predict the duration
of the coming idle
Signed-off-by: Aubrey Li <aubrey...@linux.intel.com>
---
drivers/cpuidle/Kconfig | 1 +
drivers/cpuidle/cpuidle.c | 17 -
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/d
For the governor has predict functionality, add a new predict
interface in cpuidle framework to call and use it.
---
drivers/cpuidle/cpuidle.c| 34 ++
drivers/cpuidle/governors/menu.c | 7 +++
include/linux/cpuidle.h | 3 +++
Introduce run queue average idle in scheduler as a factor to make
idle prediction
Signed-off-by: Aubrey Li <aubrey...@linux.intel.com>
---
drivers/cpuidle/cpuidle.c | 12
include/linux/cpuidle.h | 1 +
kernel/sched/idle.c | 5 +
3 files changed, 18 insertions(+)
Record the overhead of idle entry in micro-second
Signed-off-by: Aubrey Li
---
drivers/cpuidle/cpuidle.c | 33 +
include/linux/cpuidle.h | 14 ++
kernel/sched/idle.c | 8 +++-
3 files changed, 54 insertions(+), 1 deletion(-)
diff --git
Introduce irq timings output as a factor to predict the duration
of the coming idle
Signed-off-by: Aubrey Li
---
drivers/cpuidle/Kconfig | 1 +
drivers/cpuidle/cpuidle.c | 17 -
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/cpuidle/Kconfig b/drivers
For the governor has predict functionality, add a new predict
interface in cpuidle framework to call and use it.
---
drivers/cpuidle/cpuidle.c| 34 ++
drivers/cpuidle/governors/menu.c | 7 +++
include/linux/cpuidle.h | 3 +++
Introduce run queue average idle in scheduler as a factor to make
idle prediction
Signed-off-by: Aubrey Li
---
drivers/cpuidle/cpuidle.c | 12
include/linux/cpuidle.h | 1 +
kernel/sched/idle.c | 5 +
3 files changed, 18 insertions(+)
diff --git a/drivers/cpuidle
From: Aubrey Li <aubrey...@linux.intel.com>
Short idle periods occur common under some workloads, and the idle
entry and exit path starts to dominate, so it's important to optimize
them. A fast idle routine is introduced here for short idle periods.
- tick nohz enter/exit are exclued
- RC
From: Aubrey Li <aubrey...@linux.intel.com>
A generic CPU idle governor is required to make the prediction of
how long the coming idle. The statistic data taken from the existing
menu governor is attached to the per-CPU device data structure
---
include/linux/cpuidle.
From: Aubrey Li
Short idle periods occur common under some workloads, and the idle
entry and exit path starts to dominate, so it's important to optimize
them. A fast idle routine is introduced here for short idle periods.
- tick nohz enter/exit are exclued
- RCU idle enter/exit are excluded
From: Aubrey Li
A generic CPU idle governor is required to make the prediction of
how long the coming idle. The statistic data taken from the existing
menu governor is attached to the per-CPU device data structure
---
include/linux/cpuidle.h | 30 ++
1 file changed
From: Aubrey Li <aubrey...@linux.intel.com>
The system will enter a fast idle loop if the predicted idle period
is shorter than the threshold.
---
kernel/sched/idle.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
From: Aubrey Li <aubrey...@linux.intel.com>
Two factors taken from menu governor for idle prediction in the cpu
idle governor:
- Energy break even point
- Repeatable interval detector
Based on the actual known "next timer event" time, and coordinate with
the algorithm in the a
From: Aubrey Li
Two factors taken from menu governor for idle prediction in the cpu
idle governor:
- Energy break even point
- Repeatable interval detector
Based on the actual known "next timer event" time, and coordinate with
the algorithm in the above two factors, we'll make a
From: Aubrey Li
The system will enter a fast idle loop if the predicted idle period
is shorter than the threshold.
---
kernel/sched/idle.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
index cf6c11f..16a766c 100644
From: Aubrey Li <aubrey...@linux.intel.com>
For what cpuidle governor already does, we remove them from menu governor
---
drivers/cpuidle/governors/menu.c | 163 ---
1 file changed, 163 deletions(-)
diff --git a/drivers/cpuidle/governors/menu.c b/d
From: Aubrey Li
For what cpuidle governor already does, we remove them from menu governor
---
drivers/cpuidle/governors/menu.c | 163 ---
1 file changed, 163 deletions(-)
diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index
From: Aubrey Li <aubrey...@linux.intel.com>
Current cpuidle governor updates the last idle residency with the
hardware c-state exit latency, which is not applicable for fast
idle path, so we update idle residency in idle routine instead.
---
drivers/cpuidle/cpuidle.c | 13 +
From: Aubrey Li <aubrey...@linux.intel.com>
cpuidle already makes the prediction of how long the coming idle is.
We take it as the input for menu governor to select the target c-state.
---
drivers/cpuidle/governors/menu.c | 29 +
1 file changed, 5 insertions(
From: Aubrey Li <aubrey...@linux.intel.com>
Reflect the data to cpuidle governor when there is an update
---
drivers/cpuidle/cpuidle.c | 6 --
include/linux/cpuidle.h | 1 +
kernel/sched/idle.c | 14 ++
3 files changed, 19 insertions(+), 2 deletions(-)
diff
From: Aubrey Li
Current cpuidle governor updates the last idle residency with the
hardware c-state exit latency, which is not applicable for fast
idle path, so we update idle residency in idle routine instead.
---
drivers/cpuidle/cpuidle.c | 13 +
1 file changed, 5 insertions(+), 8
From: Aubrey Li
cpuidle already makes the prediction of how long the coming idle is.
We take it as the input for menu governor to select the target c-state.
---
drivers/cpuidle/governors/menu.c | 29 +
1 file changed, 5 insertions(+), 24 deletions(-)
diff --git
From: Aubrey Li
Reflect the data to cpuidle governor when there is an update
---
drivers/cpuidle/cpuidle.c | 6 --
include/linux/cpuidle.h | 1 +
kernel/sched/idle.c | 14 ++
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b
From: Aubrey Li <aubrey...@linux.intel.com>
Promote menu governor update functionality into cpuidle governor,
so that cpuidle can make a prediction based on the fresh data.
---
drivers/cpuidle/cpuidle.c | 77 +++
1 file changed, 77 insertions(+)
From: Aubrey Li <aubrey...@linux.intel.com>
Short idle periods varies from different workload, make the switch
tunable
---
include/linux/sched/sysctl.h | 1 +
kernel/sched/idle.c | 5 +++--
kernel/sysctl.c | 10 ++
3 files changed, 14 insertions(+), 2 del
From: Aubrey Li
Promote menu governor update functionality into cpuidle governor,
so that cpuidle can make a prediction based on the fresh data.
---
drivers/cpuidle/cpuidle.c | 77 +++
1 file changed, 77 insertions(+)
diff --git a/drivers/cpuidle
From: Aubrey Li
Short idle periods varies from different workload, make the switch
tunable
---
include/linux/sched/sysctl.h | 1 +
kernel/sched/idle.c | 5 +++--
kernel/sysctl.c | 10 ++
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/include
From: Aubrey Li <aubrey...@linux.intel.com>
Under some latency intensive workloads, short idle periods occurs very
common, so that idle entry and exit path starts to dominate. It's important
to optimize them for the short idle period pattern. A fast idle path proposal
is introduce
From: Aubrey Li <aubrey...@linux.intel.com>
sleep length indicates how long we'll be idle. Currently, it's updated
only when tick nohz enters. These patch series make a new requirement
with tick, so we should keep sleep length updated as needed
---
kernel/time/tick-sched.c | 3 +++
From: Aubrey Li
Under some latency intensive workloads, short idle periods occurs very
common, so that idle entry and exit path starts to dominate. It's important
to optimize them for the short idle period pattern. A fast idle path proposal
is introduced here for this purpose.
This proposal
From: Aubrey Li
sleep length indicates how long we'll be idle. Currently, it's updated
only when tick nohz enters. These patch series make a new requirement
with tick, so we should keep sleep length updated as needed
---
kernel/time/tick-sched.c | 3 +++
1 file changed, 3 insertions(+)
diff
Commit-ID: ebfa4c02fa4806bfef189e88152b833f2a732bff
Gitweb: http://git.kernel.org/tip/ebfa4c02fa4806bfef189e88152b833f2a732bff
Author: Aubrey Li <aubrey...@intel.com>
AuthorDate: Wed, 7 Jun 2017 10:49:02 +0800
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Thu, 8 Jun 2
Commit-ID: ebfa4c02fa4806bfef189e88152b833f2a732bff
Gitweb: http://git.kernel.org/tip/ebfa4c02fa4806bfef189e88152b833f2a732bff
Author: Aubrey Li
AuthorDate: Wed, 7 Jun 2017 10:49:02 +0800
Committer: Ingo Molnar
CommitDate: Thu, 8 Jun 2017 10:32:09 +0200
sched/idle: Add deferrable
Deferrable vmstat_updater was missing in commit c1de45ca831a
("sched/idle: Add support for tasks that inject idle"), add it back
Signed-off-by: Aubrey Li <aubrey...@linux.intel.com>
---
kernel/sched/idle.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/sched/idle.
Deferrable vmstat_updater was missing in commit c1de45ca831a
("sched/idle: Add support for tasks that inject idle"), add it back
Signed-off-by: Aubrey Li
---
kernel/sched/idle.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
index ef63ad
Currently the optional IPC resources prevent telemetry driver from
probing if these resources are not in ACPI table. This patch decouples
telemetry driver from these optional resources, so that telemetry driver
has dependency only on the necessary ACPI resources.
Signed-off-by: Aubrey Li <aub
Currently the optional IPC resources prevent telemetry driver from
probing if these resources are not in ACPI table. This patch decouples
telemetry driver from these optional resources, so that telemetry driver
has dependency only on the necessary ACPI resources.
Signed-off-by: Aubrey Li
Thanks.
Acked-by: Aubrey Li <[EMAIL PROTECTED]>
On 5/24/07, Alan Cox <[EMAIL PROTECTED]> wrote:
Add the needed definitions to activate arbitary speed support on the
blackfin platform.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-fro
Thanks.
Acked-by: Aubrey Li [EMAIL PROTECTED]
On 5/24/07, Alan Cox [EMAIL PROTECTED] wrote:
Add the needed definitions to activate arbitary speed support on the
blackfin platform.
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
On 5/23/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
On Mon, 21 May 2007, Bernhard Walle wrote:
> [PATCH] [scsi] Remove __GFP_DMA
>
> After 821de3a27bf33f11ec878562577c586cd5f83c64, it's not necessary to alloate
a
> DMA buffer any more in sd.c.
>
> Signed-off-by: Bernhard Walle <[EMAIL
On 5/23/07, Christoph Lameter [EMAIL PROTECTED] wrote:
On Mon, 21 May 2007, Bernhard Walle wrote:
[PATCH] [scsi] Remove __GFP_DMA
After 821de3a27bf33f11ec878562577c586cd5f83c64, it's not necessary to alloate
a
DMA buffer any more in sd.c.
Signed-off-by: Bernhard Walle [EMAIL PROTECTED]
On 4/20/07, David Howells <[EMAIL PROTECTED]> wrote:
Aubrey Li <[EMAIL PROTECTED]> wrote:
> as checked in packet_set_ring, buffer size must be a multiple of PAGE_SIZE,
> packet_set_ring
> if (unlikely(req->tp_block_size &
On 4/20/07, David Howells <[EMAIL PROTECTED]> wrote:
Aubrey Li <[EMAIL PROTECTED]> wrote:
> The patch works properly on my side. But
> 1) I'm not sure why you re-wrote alloc/free_pg_vec function, doesn't
> the current implement work for NOMMU? I know you want to alloc
On 4/20/07, David Howells [EMAIL PROTECTED] wrote:
Aubrey Li [EMAIL PROTECTED] wrote:
The patch works properly on my side. But
1) I'm not sure why you re-wrote alloc/free_pg_vec function, doesn't
the current implement work for NOMMU? I know you want to allocate the
entire data buffer as one
On 4/20/07, David Howells [EMAIL PROTECTED] wrote:
Aubrey Li [EMAIL PROTECTED] wrote:
as checked in packet_set_ring, buffer size must be a multiple of PAGE_SIZE,
packet_set_ring
if (unlikely(req-tp_block_size (PAGE_SIZE - 1)))
So why not use
On 4/18/07, David Howells <[EMAIL PROTECTED]> wrote:
Aubrey Li <[EMAIL PROTECTED]> wrote:
> Here, in the attachment I wrote a small test app. Please correct if
> there is anything wrong, and feel free to improve it.
Okay... I have that working... probably. I don't kno
On 4/18/07, David Howells [EMAIL PROTECTED] wrote:
Aubrey Li [EMAIL PROTECTED] wrote:
Here, in the attachment I wrote a small test app. Please correct if
there is anything wrong, and feel free to improve it.
Okay... I have that working... probably. I don't know what output it's
supposed
On 4/18/07, David Howells <[EMAIL PROTECTED]> wrote:
Aubrey Li <[EMAIL PROTECTED]> wrote:
> Here, in the attachment I wrote a small test app. Please correct if
> there is anything wrong, and feel free to improve it.
Okay... I have that working... probably. I don't kno
On 4/18/07, David Howells [EMAIL PROTECTED] wrote:
Aubrey Li [EMAIL PROTECTED] wrote:
Here, in the attachment I wrote a small test app. Please correct if
there is anything wrong, and feel free to improve it.
Okay... I have that working... probably. I don't know what output it's
supposed
On 4/11/07, Robin Getz <[EMAIL PROTECTED]> wrote:
On Tue 10 Apr 2007 08:55, David Howells pondered:
> Looking at alloc_pg_vec() in af_packet.c, I will place my bets on the
> latter case. I don't know that this is a problem; it depends on how things
> work, and that I don't know offhand. If
In net poll mode, the current checksum function doesn't consider the
kind of packet which is padded to reach a specific minimum length. I
believe that's the problem causing my test case failed. The following
patch fixed this issue.
Signed-off-by: Aubrey.Li <[EMAIL PROTECTED]>
---
In net poll mode, the current checksum function doesn't consider the
kind of packet which is padded to reach a specific minimum length. I
believe that's the problem causing my test case failed. The following
patch fixed this issue.
Signed-off-by: Aubrey.Li [EMAIL PROTECTED]
---
On 4/11/07, Robin Getz [EMAIL PROTECTED] wrote:
On Tue 10 Apr 2007 08:55, David Howells pondered:
Looking at alloc_pg_vec() in af_packet.c, I will place my bets on the
latter case. I don't know that this is a problem; it depends on how things
work, and that I don't know offhand. If someone
On 4/12/07, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
Aubrey Li wrote:
> I think we discussed this issue before.
>
> The current checksum function doesn't consider the kind of packet
> which is padded to reach a specific minimum length. I believe that's
> the proble
On 4/12/07, Stephen Hemminger [EMAIL PROTECTED] wrote:
Aubrey Li wrote:
I think we discussed this issue before.
The current checksum function doesn't consider the kind of packet
which is padded to reach a specific minimum length. I believe that's
the problem caused my test case failed
I think we discussed this issue before.
The current checksum function doesn't consider the kind of packet
which is padded to reach a specific minimum length. I believe that's
the problem caused my test case failed. Is this issue fixed? Or is it
acceptable if I make a patch not calculating this
I think we discussed this issue before.
The current checksum function doesn't consider the kind of packet
which is padded to reach a specific minimum length. I believe that's
the problem caused my test case failed. Is this issue fixed? Or is it
acceptable if I make a patch not calculating this
101 - 200 of 264 matches
Mail list logo
