On 01/07/2011 12:29 AM, Mike Galbraith wrote:
+#ifdef CONFIG_SMP
+ /*
+* If this yield is important enough to want to preempt instead
+* of only dropping a -next hint, we're alone, and the target
+* is not alone, pull the target to this cpu.
+*
+*
On Wed, 2011-01-12 at 22:02 -0500, Rik van Riel wrote:
Cgroups only makes the matter worse - libvirt places
each KVM guest into its own cgroup, so a VCPU will
generally always be alone on its own per-cgroup, per-cpu
runqueue! That can lead to pulling a VCPU onto our local
CPU because we
On 01/12/2011 10:26 PM, Mike Galbraith wrote:
On Wed, 2011-01-12 at 22:02 -0500, Rik van Riel wrote:
Cgroups only makes the matter worse - libvirt places
each KVM guest into its own cgroup, so a VCPU will
generally always be alone on its own per-cgroup, per-cpu
runqueue! That can lead to
...@redhat.com
Cc: Hillf Dantondhi...@gmail.com,kvm@vger.kernel.org,
linux-ker...@vger.kernel.org, Avi Kivitia...@redhat.com, Srivatsa
Vaddagiriva...@linux.vnet.ibm.com, Mike Galbraithefa...@gmx.de,
Chris Wrightchr...@sous-sol.org
Subject: Re: [RFC -v3 PATCH 2/3] sched: add yield_to function
Date
On Thu, Jan 6, 2011 at 12:57 AM, Mike Galbraith efa...@gmx.de wrote:
sched: Add yield_to(task, preempt) functionality.
Currently only implemented for fair class tasks.
Add a yield_to_task method() to the fair scheduling class. allowing the
caller of yield_to() to accelerate another thread in
On Wed, 2011-01-05 at 18:04 +0100, Peter Zijlstra wrote:
On Wed, 2011-01-05 at 17:57 +0100, Mike Galbraith wrote:
+ p_cfs_rq = cfs_rq_of(pse);
+ local = 1;
+ }
+#endif
+
+ /* Tell the scheduler that we'd really like pse to run next. */
+
On 01/05/2011 04:39 AM, KOSAKI Motohiro wrote:
On 01/04/2011 08:14 AM, KOSAKI Motohiro wrote:
Also, If pthread_cond_signal() call sys_yield_to imlicitly, we can
avoid almost Nehalem (and other P2P cache arch) lock unfairness
problem. (probaby creating
On 01/05/2011 10:40 AM, KOSAKI Motohiro wrote:
On 01/05/2011 04:39 AM, KOSAKI Motohiro wrote:
On 01/04/2011 08:14 AM, KOSAKI Motohiro wrote:
Also, If pthread_cond_signal() call sys_yield_to imlicitly, we can
avoid almost Nehalem (and other P2P cache arch) lock
On 01/05/2011 10:40 AM, KOSAKI Motohiro wrote:
On 01/05/2011 04:39 AM, KOSAKI Motohiro wrote:
On 01/04/2011 08:14 AM, KOSAKI Motohiro wrote:
Also, If pthread_cond_signal() call sys_yield_to imlicitly,
we can
avoid almost Nehalem (and other P2P cache arch)
On 01/05/2011 11:30 AM, KOSAKI Motohiro wrote:
On 01/05/2011 10:40 AM, KOSAKI Motohiro wrote:
On 01/05/2011 04:39 AM, KOSAKI Motohiro wrote:
On 01/04/2011 08:14 AM, KOSAKI Motohiro wrote:
Also, If pthread_cond_signal() call sys_yield_to
imlicitly, we can
...@vger.kernel.org, Avi Kivitia...@redhat.com, Srivatsa
Vaddagiriva...@linux.vnet.ibm.com, Mike Galbraithefa...@gmx.de,
Chris Wrightchr...@sous-sol.org
Subject: Re: [RFC -v3 PATCH 2/3] sched: add yield_to function
Date: Tue, 04 Jan 2011 19:05:54 +0100
RT guests don't make sense, there's
On Wed, 2011-01-05 at 11:39 +0900, KOSAKI Motohiro wrote:
After calling pthread_cond_signal(), T1 which cond_signal caller and T2
which waked start to GIL grab race. But usually T1 is always win because
lock variable is in T1's cpu cache. Why kernel and userland have so much
different result?
On Wed, 2011-01-05 at 17:40 +0900, KOSAKI Motohiro wrote:
If you are interesting GIL mess and issue, please feel free to ask more.
I suggest looking into an explicit round-robin scheme, where each thread
adds itself to a queue and an unlock wakes up the first waiter.
I'm sure you
It's Rik's patch to do with whatever he wants (I donated suggestion;),
but I took the liberty of cleaning it up a bit, see below. It's
essentially the same, but fixes a bug where the caller may have targeted
a task in it's thread group etc, but when preemption decision time came,
may have
On Wed, 2011-01-05 at 17:57 +0100, Mike Galbraith wrote:
+ p_cfs_rq = cfs_rq_of(pse);
+ local = 1;
+ }
+#endif
+
+ /* Tell the scheduler that we'd really like pse to run next. */
+ p_cfs_rq-next = pse;
+
+ /* We know whether we want to
On 01/04/2011 08:04 PM, Peter Zijlstra wrote:
This definitely wants to be EXPORT_SYMBOL_GPL() and if it were possible
I'd make it so only kvm.o could use it. It really sucks that kvm is a
module.
Why does it suck? I mean apart from the virtualization is crap song.
--
error compiling
On 01/05/2011 07:15 PM, Peter Zijlstra wrote:
On Wed, 2011-01-05 at 19:10 +0200, Avi Kivity wrote:
On 01/04/2011 08:04 PM, Peter Zijlstra wrote:
This definitely wants to be EXPORT_SYMBOL_GPL() and if it were possible
I'd make it so only kvm.o could use it. It really sucks that kvm is a
On Wed, 2011-01-05 at 18:04 +0100, Peter Zijlstra wrote:
On Wed, 2011-01-05 at 17:57 +0100, Mike Galbraith wrote:
+ p_cfs_rq = cfs_rq_of(pse);
+ local = 1;
+ }
+#endif
+
+ /* Tell the scheduler that we'd really like pse to run next. */
+
On Wed, 2011-01-05 at 19:19 +0200, Avi Kivity wrote:
On 01/05/2011 07:15 PM, Peter Zijlstra wrote:
On Wed, 2011-01-05 at 19:10 +0200, Avi Kivity wrote:
On 01/04/2011 08:04 PM, Peter Zijlstra wrote:
This definitely wants to be EXPORT_SYMBOL_GPL() and if it were
possible
I'd
On 01/05/2011 07:28 PM, Peter Zijlstra wrote:
On Wed, 2011-01-05 at 19:19 +0200, Avi Kivity wrote:
On 01/05/2011 07:15 PM, Peter Zijlstra wrote:
On Wed, 2011-01-05 at 19:10 +0200, Avi Kivity wrote:
On 01/04/2011 08:04 PM, Peter Zijlstra wrote:
This definitely wants to be
On Wed, 2011-01-05 at 19:35 +0200, Avi Kivity wrote:
Tejun, why did you end up not using preempt_notifiers in cmwq?
Because I told him to use explicit function calls because that keeps the
code easier to read.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a
On Wed, 2011-01-05 at 19:10 +0200, Avi Kivity wrote:
On 01/04/2011 08:04 PM, Peter Zijlstra wrote:
This definitely wants to be EXPORT_SYMBOL_GPL() and if it were possible
I'd make it so only kvm.o could use it. It really sucks that kvm is a
module.
Why does it suck? I mean apart from
On 01/04/2011 08:14 AM, KOSAKI Motohiro wrote:
Also, If pthread_cond_signal() call sys_yield_to imlicitly, we can
avoid almost Nehalem (and other P2P cache arch) lock unfairness
problem. (probaby creating pthread_condattr_setautoyield_np or similar
knob is good one)
Often, the thread calling
On Tue, Jan 4, 2011 at 5:29 AM, Rik van Riel r...@redhat.com wrote:
From: Mike Galbraith efa...@gmx.de
Add a yield_to function to the scheduler code, allowing us to
give enough of our timeslice to another thread to allow it to
run and release whatever resource we need it to release.
We may
On Tue, Jan 4, 2011 at 5:29 AM, Rik van Riel r...@redhat.com wrote:
From: Mike Galbraith efa...@gmx.de
Add a yield_to function to the scheduler code, allowing us to
give enough of our timeslice to another thread to allow it to
run and release whatever resource we need it to release.
We may
On 01/04/2011 11:41 AM, Hillf Danton wrote:
/* !curr-sched_class-yield_to_task ||*/
+ curr-sched_class != p-sched_class) {
+ goto out;
+ }
+
/*
* ask scheduler to compute the next for successfully
On Wed, Jan 5, 2011 at 12:44 AM, Rik van Riel r...@redhat.com wrote:
On 01/04/2011 11:41 AM, Hillf Danton wrote:
/* !curr-sched_class-yield_to_task || */
+ curr-sched_class != p-sched_class) {
+ goto out;
+ }
+
On 01/04/2011 11:51 AM, Hillf Danton wrote:
Wouldn't that break for FIFO and RR tasks?
There's a reason all the scheduler folks wanted a
per-class yield_to_task function :)
Where is the yield_to callback in the patch for RT schedule class?
If @p is RT, what could you do?
If the user
On Wed, Jan 5, 2011 at 12:54 AM, Rik van Riel r...@redhat.com wrote:
On 01/04/2011 11:51 AM, Hillf Danton wrote:
Wouldn't that break for FIFO and RR tasks?
There's a reason all the scheduler folks wanted a
per-class yield_to_task function :)
Where is the yield_to callback in the patch for
On Wed, 2011-01-05 at 00:51 +0800, Hillf Danton wrote:
Where is the yield_to callback in the patch for RT schedule class?
If @p is RT, what could you do?
RT guests are a pipe dream, you first need to get the hypervisor (kvm in
this case) to be RT, which it isn't. Then you either need to very
On Wed, Jan 5, 2011 at 1:08 AM, Peter Zijlstra a.p.zijls...@chello.nl wrote:
On Wed, 2011-01-05 at 00:51 +0800, Hillf Danton wrote:
Where is the yield_to callback in the patch for RT schedule class?
If @p is RT, what could you do?
RT guests are a pipe dream, you first need to get the
On Tue, 2011-01-04 at 15:14 +0900, KOSAKI Motohiro wrote:
From: Mike Galbraith efa...@gmx.de
Add a yield_to function to the scheduler code, allowing us to
give enough of our timeslice to another thread to allow it to
run and release whatever resource we need it to release.
We may
On Wed, 2011-01-05 at 01:12 +0800, Hillf Danton wrote:
On Wed, Jan 5, 2011 at 1:08 AM, Peter Zijlstra a.p.zijls...@chello.nl wrote:
On Wed, 2011-01-05 at 00:51 +0800, Hillf Danton wrote:
Where is the yield_to callback in the patch for RT schedule class?
If @p is RT, what could you do?
On 01/04/2011 12:08 PM, Peter Zijlstra wrote:
On Wed, 2011-01-05 at 00:51 +0800, Hillf Danton wrote:
Where is the yield_to callback in the patch for RT schedule class?
If @p is RT, what could you do?
RT guests are a pipe dream, you first need to get the hypervisor (kvm in
this case) to be RT,
On Mon, 2011-01-03 at 16:29 -0500, Rik van Riel wrote:
From: Mike Galbraith efa...@gmx.de
Add a yield_to function to the scheduler code, allowing us to
give enough of our timeslice to another thread to allow it to
run and release whatever resource we need it to release.
We may want to use
On Tue, 2011-01-04 at 19:04 +0100, Peter Zijlstra wrote:
+ p_cfs_rq = cfs_rq_of(pse);
+ yield = 1;
+ }
+#endif
+
+ if (yield)
+ clear_buddies(cfs_rq, se);
+ else if (preempt)
+ clear_buddies(p_cfs_rq, curr);
+
+ /* Tell the
...@linux.vnet.ibm.com, Mike Galbraithefa...@gmx.de,
Chris Wrightchr...@sous-sol.org
Subject: Re: [RFC -v3 PATCH 2/3] sched: add yield_to function
Date: Tue, 04 Jan 2011 19:05:54 +0100
RT guests don't make sense, there's nowhere near enough infrastructure
for that to work well.
I'd argue that KVM
Il 05/01/2011 00:38, Tommaso Cucinotta ha scritto:
Of course, don't misunderstand me: this is a necessary condition for a
stable performance of KVM VMs, I'm not saying it is sufficient for
... it.
Please, comment on this (reply to all, please, I'm not following LKML).
Thanks,
Tommaso
--
On 01/04/2011 08:14 AM, KOSAKI Motohiro wrote:
Also, If pthread_cond_signal() call sys_yield_to imlicitly, we can
avoid almost Nehalem (and other P2P cache arch) lock unfairness
problem. (probaby creating pthread_condattr_setautoyield_np or similar
knob is good one)
Often, the thread
NAK NAK NAK, yield_to is utter crap, and the only reason kvm 'needs' it
is because its wants to be utter crap (run unmodified guests).
There is plenty of sane serialization primitives for userspace, fix your
locking mess instead of pushing crap.
The only reason I'm maybe half-way
From: Mike Galbraith efa...@gmx.de
Add a yield_to function to the scheduler code, allowing us to
give enough of our timeslice to another thread to allow it to
run and release whatever resource we need it to release.
We may want to use this to provide a sys_yield_to system call
one day.
On Mon, 2011-01-03 at 16:29 -0500, Rik van Riel wrote:
From: Mike Galbraith efa...@gmx.de
Add a yield_to function to the scheduler code, allowing us to
give enough of our timeslice to another thread to allow it to
run and release whatever resource we need it to release.
We may want to use
From: Mike Galbraith efa...@gmx.de
Add a yield_to function to the scheduler code, allowing us to
give enough of our timeslice to another thread to allow it to
run and release whatever resource we need it to release.
We may want to use this to provide a sys_yield_to system call
one day.
43 matches
Mail list logo
