On 10/22/07, Paul Jackson [EMAIL PROTECTED] wrote:
Steven wrote:
+void cpuset_rt_set_overload(struct task_struct *tsk, int cpu)
+{
+ cpu_set(cpu, task_cs(tsk)-rt_overload);
+}
Question for Steven:
What locks are held when cpuset_rt_set_overload() is called?
Questions for Paul
Paul M wrote:
Cgroups doesn't change the locking rules for accessing a cpuset from a
task - you have to have one of:
Good - could you comment task_cs() with this explanation?
The rules are derived from the cpuset rules, as you explain,
and as I suspected, but now task_cs() is the most popular
Sven-Thorsten Dietrich wrote:
On Mon, 2007-10-22 at 09:01 +0200, Back, Michael (ext) wrote:
Hallo,
I tried to run Windows XP with KVM on Linux 2.6.31.1 on a
You mean .21.1 ?
Classic typo I interestingly also did several times the last week. :)
AMD Opteron and on a Intel Xeon, on both
* Steven Rostedt [EMAIL PROTECTED] wrote:
Changes since V1:
Updated to git tree 55b70a0300b873c0ec7ea6e33752af56f41250ce
Various clean ups suggested by Gregory Haskins, Dmitry Adamushko,
and Peter Zijlstra.
ok, i like this new approach - nice work! I'd suggest we test it in
On Tue, 2007-10-23 at 10:35 +0200, Jan Kiszka wrote:
Sven-Thorsten Dietrich wrote:
On Mon, 2007-10-22 at 09:01 +0200, Back, Michael (ext) wrote:
Hallo,
I tried to run Windows XP with KVM on Linux 2.6.31.1 on a
You mean .21.1 ?
Classic typo I interestingly also did several times
--
On Mon, 22 Oct 2007, Paul Menage wrote:
On 10/22/07, Paul Jackson [EMAIL PROTECTED] wrote:
Steven wrote:
+void cpuset_rt_set_overload(struct task_struct *tsk, int cpu)
+{
+ cpu_set(cpu, task_cs(tsk)-rt_overload);
+}
Question for Steven:
What locks are held when
Hello everyone,
I have an x86 system with two PCI slots, in which I inserted two
specialized output cards (Dektec DTA-105).
http://www.dektec.com/Products/DTA-105/
(They provide an open source driver.)
My problem is: when I write to the 4 ports (each card has 2 ports) at
the same time (not
http://rt.wiki.kernel.org/index.php/Preemption_Test
Thanks to Darren Hart for fixing the permissions on the site for me.
And thanks to Steven Rostedt for inspiring this test.
(Steve, feel free to edit the page to include your test as well)
-Greg
signature.asc
Description: This is a digitally
This is version 5 of the patch series against 23-rt1.
There have been numerous fixes/tweaks since v4, though we still are based on
the global rto_cpumask logic instead of Steve/Ingo's cpuset logic. Otherwise,
it's in pretty good shape.
Without the series applied, the following test will fail:
From: Steven Rostedt [EMAIL PROTECTED]
Signed-off-by: Steven Rostedt [EMAIL PROTECTED]
---
kernel/sched.c| 141 ++---
kernel/sched_rt.c | 44 +
2 files changed, 178 insertions(+), 7 deletions(-)
diff --git a/kernel/sched.c
We inadvertently added a redundant function, so clean it up
Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
---
kernel/sched.c|9 +
kernel/sched_rt.c | 44
2 files changed, 5 insertions(+), 48 deletions(-)
diff --git
A little cleanup to avoid #ifdef proliferation later in the series
Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
---
kernel/sched.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/kernel/sched.c b/kernel/sched.c
index e22eec7..dfd0b92 100644
---
This is an implementation of Steve's idea where we should update the RQ
concept of priority to show the highest-task, even if that task is not (yet)
running. This prevents us from pushing multiple tasks to the RQ before it
gets a chance to reschedule.
Signed-off-by: Gregory Haskins [EMAIL
There are three events that require consideration for redistributing RT
tasks:
1) When one or more higher-priority tasks preempts a lower-one from a
RQ
2) When a lower-priority task is woken up on a RQ
3) When a RQ downgrades its current priority
Steve Rostedt's push_rt patch addresses (1).
We can avoid dirtying a rq related cacheline with a simple check, so why not.
Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
---
kernel/sched.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/kernel/sched.c b/kernel/sched.c
index e536142..1058a1f 100644
---
From: Steven Rostedt [EMAIL PROTECTED]
Steve found these errors in the original patch
Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
---
kernel/sched.c| 15 -
kernel/sched_rt.c | 90 +
2 files changed, 15 insertions(+), 90
We only need to track if the CPU is in a non-RT state, as opposed to its
priority within the non-RT state. So simplify setting in the effort of
reducing cache-thrash.
Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
---
kernel/sched.c |8
1 files changed, 8 insertions(+), 0
This code tracks the priority of each CPU so that global migration
decisions are easy to calculate. Each CPU can be in a state as follows:
(INVALID), IDLE, NORMAL, RT1, ... RT99
going from the lowest priority to the highest. CPUs in the INVALID state
are not eligible for
Some RT tasks (particularly kthreads) are bound to one specific CPU.
It is fairly common for one or more bound tasks to get queued up at the
same time. Consider, for instance, softirq_timer and softirq_sched. A
timer goes off in an ISR which schedules softirq_thread to run at RT50.
Then during
19 matches
Mail list logo
