If there are no objections, now that the merge window closed, could this
be considered for v4.19?
Thanks,
Davidlohr
On Tue, 10 Apr 2018, Davidlohr Bueso wrote:
By applying well known spin-on-lock-owner techniques, we can avoid the
blocking overhead during the process of when the task is
If there are no objections, now that the merge window closed, could this
be considered for v4.19?
Thanks,
Davidlohr
On Tue, 10 Apr 2018, Davidlohr Bueso wrote:
By applying well known spin-on-lock-owner techniques, we can avoid the
blocking overhead during the process of when the task is
On Fri, 20 Apr 2018, Mike Galbraith wrote:
On Fri, 2018-04-20 at 17:50 +0200, Peter Zijlstra wrote:
Is this similar to what we have in RT (which, IIRC, has an optimistic
spinning implementation as well)?
For the RT spinlock replacement, the top waiter can spin.
Yeah and the difference with
On Fri, 20 Apr 2018, Mike Galbraith wrote:
On Fri, 2018-04-20 at 17:50 +0200, Peter Zijlstra wrote:
Is this similar to what we have in RT (which, IIRC, has an optimistic
spinning implementation as well)?
For the RT spinlock replacement, the top waiter can spin.
Yeah and the difference with
On Fri, 2018-04-20 at 17:50 +0200, Peter Zijlstra wrote:
> On Tue, Apr 10, 2018 at 09:27:50AM -0700, Davidlohr Bueso wrote:
> > By applying well known spin-on-lock-owner techniques, we can avoid the
> > blocking overhead during the process of when the task is trying to take
> > the rtmutex. The
On Fri, 2018-04-20 at 17:50 +0200, Peter Zijlstra wrote:
> On Tue, Apr 10, 2018 at 09:27:50AM -0700, Davidlohr Bueso wrote:
> > By applying well known spin-on-lock-owner techniques, we can avoid the
> > blocking overhead during the process of when the task is trying to take
> > the rtmutex. The
On Tue, Apr 10, 2018 at 09:27:50AM -0700, Davidlohr Bueso wrote:
> By applying well known spin-on-lock-owner techniques, we can avoid the
> blocking overhead during the process of when the task is trying to take
> the rtmutex. The idea is that as long as the owner is running, there is a
> fair
On Tue, Apr 10, 2018 at 09:27:50AM -0700, Davidlohr Bueso wrote:
> By applying well known spin-on-lock-owner techniques, we can avoid the
> blocking overhead during the process of when the task is trying to take
> the rtmutex. The idea is that as long as the owner is running, there is a
> fair
On Wed, 11 Apr 2018, kbuild test robot wrote:
Hi Davidlohr,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.16 next-20180411]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the
On Wed, 11 Apr 2018, kbuild test robot wrote:
Hi Davidlohr,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.16 next-20180411]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the
Hi Davidlohr,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.16 next-20180411]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
Hi Davidlohr,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.16 next-20180411]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
12 matches
Mail list logo