On Thu, 06 Sep 2018, Peter Zijlstra wrote:
On Fri, Jul 20, 2018 at 01:05:59PM -0700, Davidlohr Bueso wrote:
On Fri, 20 Jul 2018, Andrew Morton wrote:
>I'm surprised. Is spin_lock_irqsave() significantly more expensive
>than spin_lock_irq()? Relative to all the other stuff those functions
On Thu, 06 Sep 2018, Peter Zijlstra wrote:
On Fri, Jul 20, 2018 at 01:05:59PM -0700, Davidlohr Bueso wrote:
On Fri, 20 Jul 2018, Andrew Morton wrote:
>I'm surprised. Is spin_lock_irqsave() significantly more expensive
>than spin_lock_irq()? Relative to all the other stuff those functions
On Fri, Jul 20, 2018 at 01:05:59PM -0700, Davidlohr Bueso wrote:
> On Fri, 20 Jul 2018, Andrew Morton wrote:
> >I'm surprised. Is spin_lock_irqsave() significantly more expensive
> >than spin_lock_irq()? Relative to all the other stuff those functions
> >are doing? If so, how come? Some
On Fri, Jul 20, 2018 at 01:05:59PM -0700, Davidlohr Bueso wrote:
> On Fri, 20 Jul 2018, Andrew Morton wrote:
> >I'm surprised. Is spin_lock_irqsave() significantly more expensive
> >than spin_lock_irq()? Relative to all the other stuff those functions
> >are doing? If so, how come? Some
On Sat, 21 Jul 2018 11:31:27 -0700 Davidlohr Bueso wrote:
> On Sat, 21 Jul 2018, Peter Zijlstra wrote:
>
> >On Sat, Jul 21, 2018 at 10:21:20AM -0700, Davidlohr Bueso wrote:
> >> On Fri, 20 Jul 2018, Andrew Morton wrote:
> >>
> >> > We could open-code it locally. Add a couple of
> >> >
On Sat, 21 Jul 2018 11:31:27 -0700 Davidlohr Bueso wrote:
> On Sat, 21 Jul 2018, Peter Zijlstra wrote:
>
> >On Sat, Jul 21, 2018 at 10:21:20AM -0700, Davidlohr Bueso wrote:
> >> On Fri, 20 Jul 2018, Andrew Morton wrote:
> >>
> >> > We could open-code it locally. Add a couple of
> >> >
On Sat, 21 Jul 2018, Peter Zijlstra wrote:
On Sat, Jul 21, 2018 at 10:21:20AM -0700, Davidlohr Bueso wrote:
On Fri, 20 Jul 2018, Andrew Morton wrote:
> We could open-code it locally. Add a couple of
> WARN_ON_ONCE(irqs_disabled())? That might need re-benchmarking with
> Xen but surely just
On Sat, 21 Jul 2018, Peter Zijlstra wrote:
On Sat, Jul 21, 2018 at 10:21:20AM -0700, Davidlohr Bueso wrote:
On Fri, 20 Jul 2018, Andrew Morton wrote:
> We could open-code it locally. Add a couple of
> WARN_ON_ONCE(irqs_disabled())? That might need re-benchmarking with
> Xen but surely just
On Sat, Jul 21, 2018 at 10:21:20AM -0700, Davidlohr Bueso wrote:
> On Fri, 20 Jul 2018, Andrew Morton wrote:
>
> > We could open-code it locally. Add a couple of
> > WARN_ON_ONCE(irqs_disabled())? That might need re-benchmarking with
> > Xen but surely just reading the thing isn't too
On Sat, Jul 21, 2018 at 10:21:20AM -0700, Davidlohr Bueso wrote:
> On Fri, 20 Jul 2018, Andrew Morton wrote:
>
> > We could open-code it locally. Add a couple of
> > WARN_ON_ONCE(irqs_disabled())? That might need re-benchmarking with
> > Xen but surely just reading the thing isn't too
On Fri, 20 Jul 2018, Andrew Morton wrote:
We could open-code it locally. Add a couple of
WARN_ON_ONCE(irqs_disabled())? That might need re-benchmarking with
Xen but surely just reading the thing isn't too expensive?
We could also pass on the responsibility to lockdep and just use
On Fri, 20 Jul 2018, Andrew Morton wrote:
We could open-code it locally. Add a couple of
WARN_ON_ONCE(irqs_disabled())? That might need re-benchmarking with
Xen but surely just reading the thing isn't too expensive?
We could also pass on the responsibility to lockdep and just use
On Fri, 20 Jul 2018, Andrew Morton wrote:
Did you try measuring it on bare hardware?
I did and wasn't expecting much difference.
For a 2-socket 40-core (ht) IvyBridge on a few workloads, unfortunately
I don't have a xen environment and the results for Xen I do have (which numbers
are in
On Fri, 20 Jul 2018, Andrew Morton wrote:
Did you try measuring it on bare hardware?
I did and wasn't expecting much difference.
For a 2-socket 40-core (ht) IvyBridge on a few workloads, unfortunately
I don't have a xen environment and the results for Xen I do have (which numbers
are in
On Fri, 20 Jul 2018 13:05:59 -0700 Davidlohr Bueso wrote:
> On Fri, 20 Jul 2018, Andrew Morton wrote:
>
> >On Fri, 20 Jul 2018 10:29:54 -0700 Davidlohr Bueso wrote:
> >
> >> Hi,
> >>
> >> Both patches replace saving+restoring interrupts when taking the
> >> ep->lock (now the waitqueue lock),
On Fri, 20 Jul 2018 13:05:59 -0700 Davidlohr Bueso wrote:
> On Fri, 20 Jul 2018, Andrew Morton wrote:
>
> >On Fri, 20 Jul 2018 10:29:54 -0700 Davidlohr Bueso wrote:
> >
> >> Hi,
> >>
> >> Both patches replace saving+restoring interrupts when taking the
> >> ep->lock (now the waitqueue lock),
On Fri, 20 Jul 2018, Andrew Morton wrote:
On Fri, 20 Jul 2018 10:29:54 -0700 Davidlohr Bueso wrote:
Hi,
Both patches replace saving+restoring interrupts when taking the
ep->lock (now the waitqueue lock), with just disabling local irqs.
This shows immediate performance benefits in patch 1
On Fri, 20 Jul 2018, Andrew Morton wrote:
On Fri, 20 Jul 2018 10:29:54 -0700 Davidlohr Bueso wrote:
Hi,
Both patches replace saving+restoring interrupts when taking the
ep->lock (now the waitqueue lock), with just disabling local irqs.
This shows immediate performance benefits in patch 1
On Fri, 20 Jul 2018 10:29:54 -0700 Davidlohr Bueso wrote:
> Hi,
>
> Both patches replace saving+restoring interrupts when taking the
> ep->lock (now the waitqueue lock), with just disabling local irqs.
> This shows immediate performance benefits in patch 1 for an epoll
> workload running on
On Fri, 20 Jul 2018 10:29:54 -0700 Davidlohr Bueso wrote:
> Hi,
>
> Both patches replace saving+restoring interrupts when taking the
> ep->lock (now the waitqueue lock), with just disabling local irqs.
> This shows immediate performance benefits in patch 1 for an epoll
> workload running on
Hi,
Both patches replace saving+restoring interrupts when taking the
ep->lock (now the waitqueue lock), with just disabling local irqs.
This shows immediate performance benefits in patch 1 for an epoll
workload running on Xen. The main concern we need to have with this
sort of changes in epoll is
Hi,
Both patches replace saving+restoring interrupts when taking the
ep->lock (now the waitqueue lock), with just disabling local irqs.
This shows immediate performance benefits in patch 1 for an epoll
workload running on Xen. The main concern we need to have with this
sort of changes in epoll is
22 matches
Mail list logo
