On Mon, Mar 13, 2017 at 03:25:52PM +0100, Thomas Gleixner wrote:
> On Mon, 13 Mar 2017, Peter Zijlstra wrote:
>
> > On Tue, Mar 07, 2017 at 03:31:50PM +0100, Thomas Gleixner wrote:
> > > On Sat, 4 Mar 2017, Peter Zijlstra wrote:
> > >
> > > > The problem with returning -EAGAIN when the waiter sta
On Mon, 13 Mar 2017, Peter Zijlstra wrote:
> On Tue, Mar 07, 2017 at 03:31:50PM +0100, Thomas Gleixner wrote:
> > On Sat, 4 Mar 2017, Peter Zijlstra wrote:
> >
> > > The problem with returning -EAGAIN when the waiter state mismatches is
> > > that it becomes very hard to proof a bounded execution
On Tue, Mar 07, 2017 at 03:31:50PM +0100, Thomas Gleixner wrote:
> On Sat, 4 Mar 2017, Peter Zijlstra wrote:
>
> > The problem with returning -EAGAIN when the waiter state mismatches is
> > that it becomes very hard to proof a bounded execution time on the
> > operation. And seeing that this is a
On Tue, Mar 07, 2017 at 03:31:50PM +0100, Thomas Gleixner wrote:
> On Sat, 4 Mar 2017, Peter Zijlstra wrote:
>
> > The problem with returning -EAGAIN when the waiter state mismatches is
> > that it becomes very hard to proof a bounded execution time on the
> > operation. And seeing that this is a
On Sat, 4 Mar 2017, Peter Zijlstra wrote:
> The problem with returning -EAGAIN when the waiter state mismatches is
> that it becomes very hard to proof a bounded execution time on the
> operation. And seeing that this is a RT operation, this is somewhat
> important.
>
> While in practise it will
The problem with returning -EAGAIN when the waiter state mismatches is
that it becomes very hard to proof a bounded execution time on the
operation. And seeing that this is a RT operation, this is somewhat
important.
While in practise it will be very unlikely to ever really take more
than one or t
6 matches
Mail list logo