On Fri, 7 Aug 2015, Peter Zijlstra wrote:
On Fri, Aug 07, 2015 at 12:57:38PM +0200, Peter Zijlstra wrote:
+void __finish_swait(struct swait_queue_head *q, struct swait_queue
*wait)
this one has no users the __ suggests that it is locked edition. Maybe
it is for the completions…
On Fri, Aug 07, 2015 at 06:45:26PM +0200, Peter Zijlstra wrote:
Its just the swait_wake_all() that is not. The entire purpose of them
was to have something that allows bounded execution (RT and all).
Still not sure i that might be a too big burden for mainline, but at
least it's not as severe..
On Fri, Aug 07, 2015 at 12:57:38PM +0200, Peter Zijlstra wrote:
+void __finish_swait(struct swait_queue_head *q, struct swait_queue *wait)
this one has no users the __ suggests that it is locked edition. Maybe
it is for the completions…
Yeah, who knows, I certainly do not anymore ;-)
On Wed, Feb 25, 2015 at 10:02:50PM +0100, Sebastian Andrzej Siewior wrote:
+static inline int swait_active(struct swait_queue_head *q)
+{
+return !list_empty(q-task_list);
In RT there was a smp_mb() which you dropped and I assume you had
reasons for it.
Yeah, RT didn't have a reason
On Fri, Aug 07, 2015 at 01:14:15PM +0200, Peter Zijlstra wrote:
On that, we cannot convert completions to swait. Because swait wake_all
must not happen from IRQ context, and complete_all() typically is used
from just that.
If swait queues aren't useable from IRQ context they will be fairly
On Fri, Aug 07, 2015 at 09:41:31AM -0700, Christoph Hellwig wrote:
On Fri, Aug 07, 2015 at 01:14:15PM +0200, Peter Zijlstra wrote:
On that, we cannot convert completions to swait. Because swait wake_all
must not happen from IRQ context, and complete_all() typically is used
from just that.
The problem:
On -RT, an emulated LAPIC timer instances has the following path:
1) hard interrupt
2) ksoftirqd is scheduled
3) ksoftirqd wakes up vcpu thread
4) vcpu thread is scheduled
This extra context switch introduces unnecessary latency in the
LAPIC path for a KVM guest.
The solution:
* Marcelo Tosatti | 2015-01-14 15:12:52 [-0200]:
Against which tree was this prepared? Could please rebase it against
v3.18.7-rt2? Because a I see fuzz 2, the mips file is gone and
s390 rejects almost every chunk.
And there was that mips chunk Steven noticed.
Patch #2 seems to apply but since it
On Thu, Feb 26, 2015 at 09:23:57PM -0300, Marcelo Tosatti wrote:
On Tue, Feb 17, 2015 at 06:44:19PM +0100, Sebastian Andrzej Siewior wrote:
* Peter Zijlstra | 2015-01-21 16:07:16 [+0100]:
On Tue, Jan 20, 2015 at 01:16:13PM -0500, Steven Rostedt wrote:
I'm actually wondering if we should
On 03/05/2015 02:09 AM, Marcelo Tosatti wrote:
Can you please include the series?
Thanks
Sebastian?
I will pick it up, don't worry. I think I do my -RT day tomorrow.
Sebastian
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
On Tue, Feb 17, 2015 at 06:44:19PM +0100, Sebastian Andrzej Siewior wrote:
* Peter Zijlstra | 2015-01-21 16:07:16 [+0100]:
On Tue, Jan 20, 2015 at 01:16:13PM -0500, Steven Rostedt wrote:
I'm actually wondering if we should just nuke the _interruptible()
version of swait. As it should only
* Peter Zijlstra | 2015-02-18 15:03:20 [+0100]:
On Tue, Feb 17, 2015 at 06:44:19PM +0100, Sebastian Andrzej Siewior wrote:
* Peter Zijlstra | 2015-01-21 16:07:16 [+0100]:
On Tue, Jan 20, 2015 at 01:16:13PM -0500, Steven Rostedt wrote:
I'm actually wondering if we should just nuke the
On Tue, Feb 17, 2015 at 06:44:19PM +0100, Sebastian Andrzej Siewior wrote:
* Peter Zijlstra | 2015-01-21 16:07:16 [+0100]:
On Tue, Jan 20, 2015 at 01:16:13PM -0500, Steven Rostedt wrote:
I'm actually wondering if we should just nuke the _interruptible()
version of swait. As it should only
* Peter Zijlstra | 2015-01-21 16:07:16 [+0100]:
On Tue, Jan 20, 2015 at 01:16:13PM -0500, Steven Rostedt wrote:
I'm actually wondering if we should just nuke the _interruptible()
version of swait. As it should only be all interruptible or all not
interruptible, that the swait_wake() should
The problem:
On -RT, an emulated LAPIC timer instances has the following path:
1) hard interrupt
2) ksoftirqd is scheduled
3) ksoftirqd wakes up vcpu thread
4) vcpu thread is scheduled
This extra context switch introduces unnecessary latency in the
LAPIC path for a KVM guest.
The solution:
On Tue, Jan 20, 2015 at 01:16:13PM -0500, Steven Rostedt wrote:
I'm actually wondering if we should just nuke the _interruptible()
version of swait. As it should only be all interruptible or all not
interruptible, that the swait_wake() should just do the wake up
regardless. In which case,
On Tue, 20 Jan 2015 16:46:53 +1100
Paul Mackerras pau...@samba.org wrote:
On Mon, Jan 19, 2015 at 12:41:00PM -0200, Marcelo Tosatti wrote:
On Fri, Jan 16, 2015 at 11:48:46AM -0500, Steven Rostedt wrote:
static void kvmppc_vcore_blocked(struct kvmppc_vcore *vc)
{
-
On Mon, Jan 19, 2015 at 12:41:00PM -0200, Marcelo Tosatti wrote:
On Fri, Jan 16, 2015 at 11:48:46AM -0500, Steven Rostedt wrote:
static void kvmppc_vcore_blocked(struct kvmppc_vcore *vc)
{
- DEFINE_WAIT(wait);
+ DEFINE_SWAITER(wait);
- prepare_to_wait(vc-wq, wait,
On Fri, Jan 16, 2015 at 11:48:46AM -0500, Steven Rostedt wrote:
@@ -971,8 +971,8 @@
kvm_mips_callbacks-queue_timer_int(vcpu);
vcpu-arch.wait = 0;
- if (waitqueue_active(vcpu-wq)) {
- wake_up_interruptible(vcpu-wq);
+ if (swaitqueue_active(vcpu-wq)) {
+
On Fri, 16 Jan 2015 11:48:46 -0500
Steven Rostedt rost...@goodmis.org wrote:
static void kvmppc_vcore_blocked(struct kvmppc_vcore *vc)
{
- DEFINE_WAIT(wait);
+ DEFINE_SWAITER(wait);
- prepare_to_wait(vc-wq, wait, TASK_INTERRUPTIBLE);
+ swait_prepare(vc-wq, wait,
On Fri, 16 Jan 2015 11:40:45 -0500
Marcelo Tosatti mtosa...@redhat.com wrote:
The problem:
On -RT, an emulated LAPIC timer instances has the following path:
1) hard interrupt
2) ksoftirqd is scheduled
3) ksoftirqd wakes up vcpu thread
4) vcpu thread is scheduled
This extra context
On Fri, Jan 16, 2015 at 11:48:46AM -0500, Steven Rostedt wrote:
I notice everywhere you have a swait_wake_interruptible() but here. Is
there a reason why?
IIRC, Peter wants to make swait wakeup usage homogenous. That is, you
either sleep in an interruptible state, or you don't. You can't mix
The problem:
On -RT, an emulated LAPIC timer instances has the following path:
1) hard interrupt
2) ksoftirqd is scheduled
3) ksoftirqd wakes up vcpu thread
4) vcpu thread is scheduled
This extra context switch introduces unnecessary latency in the
LAPIC path for a KVM guest.
The solution:
On 01/14/2015 12:12 PM, Marcelo Tosatti wrote:
The problem:
On -RT, an emulated LAPIC timer instances has the following path:
1) hard interrupt
2) ksoftirqd is scheduled
3) ksoftirqd wakes up vcpu thread
4) vcpu thread is scheduled
This extra context switch introduces unnecessary
The problem:
On -RT, an emulated LAPIC timer instances has the following path:
1) hard interrupt
2) ksoftirqd is scheduled
3) ksoftirqd wakes up vcpu thread
4) vcpu thread is scheduled
This extra context switch introduces unnecessary latency in the
LAPIC path for a KVM guest.
The solution:
On 11/25/2014 12:21 PM, Marcelo Tosatti wrote:
The problem:
On -RT, an emulated LAPIC timer instances has the following path:
1) hard interrupt
2) ksoftirqd is scheduled
3) ksoftirqd wakes up vcpu thread
4) vcpu thread is scheduled
This extra context switch introduces unnecessary
On 11/25/2014 01:57 PM, Rik van Riel wrote:
On 11/25/2014 12:21 PM, Marcelo Tosatti wrote:
The problem:
On -RT, an emulated LAPIC timer instances has the following path:
1) hard interrupt
2) ksoftirqd is scheduled
3) ksoftirqd wakes up vcpu thread
4) vcpu thread is scheduled
This extra
On Tue, Nov 25, 2014 at 01:57:37PM -0500, Rik van Riel wrote:
On 11/25/2014 12:21 PM, Marcelo Tosatti wrote:
The problem:
On -RT, an emulated LAPIC timer instances has the following path:
1) hard interrupt
2) ksoftirqd is scheduled
3) ksoftirqd wakes up vcpu thread
4) vcpu
On Tue, 25 Nov 2014, Rik van Riel wrote:
On 11/25/2014 12:21 PM, Marcelo Tosatti wrote:
The problem:
On -RT, an emulated LAPIC timer instances has the following path:
1) hard interrupt
2) ksoftirqd is scheduled
3) ksoftirqd wakes up vcpu thread
4) vcpu thread is scheduled
29 matches
Mail list logo
