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
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
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 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
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 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
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(>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
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.
* 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
* 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 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 linux-kernel" in
the body of a message to
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
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 linux-kernel 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
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
* 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
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()
* 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,
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 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 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(>wq,
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(>wq)) {
> > - wake_up_interruptible(>wq);
> > + if (swaitqueue_active(>wq)) {
> > +
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, 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
On Fri, 16 Jan 2015 11:48:46 -0500
Steven Rostedt wrote:
> > static void kvmppc_vcore_blocked(struct kvmppc_vcore *vc)
> > {
> > - DEFINE_WAIT(wait);
> > + DEFINE_SWAITER(wait);
> >
> > - prepare_to_wait(>wq, , TASK_INTERRUPTIBLE);
> > + swait_prepare(>wq, , TASK_INTERRUPTIBLE);
> >
On Fri, 16 Jan 2015 11:40:45 -0500
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
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, 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, 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
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
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:
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
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
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
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
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
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:
This allows waking up vcpu thread from hardirq context.
Signed-off-by: Marcelo Tosatti
---
arch/arm/kvm/arm.c |4 ++--
arch/arm/kvm/psci.c |4 ++--
arch/mips/kvm/kvm_mips.c|8
arch/powerpc/include/asm/kvm_host.h |4 ++--
This allows waking up vcpu thread from hardirq context.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
---
arch/arm/kvm/arm.c |4 ++--
arch/arm/kvm/psci.c |4 ++--
arch/mips/kvm/kvm_mips.c|8
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
58 matches
Mail list logo
