On Sat, 2013-11-23 at 13:01 +0100, Peter Zijlstra wrote:
> > I used to have a patch to schedule() that would always immediately fall
> > through and only actually block on the second call; it illustrated the
> > problem really well, in fact so well the kernels fails to boot most
> > times.
>
> I
> I used to have a patch to schedule() that would always immediately fall
> through and only actually block on the second call; it illustrated the
> problem really well, in fact so well the kernels fails to boot most
> times.
I found the below on my filesystem -- making it apply shouldn't be
On Fri, Nov 22, 2013 at 04:56:37PM -0800, Davidlohr Bueso wrote:
> From: Peter Zijlstra
>
> Original patchset: https://lkml.org/lkml/2011/9/14/118
>
> This is useful for locking primitives that can effect multiple
> wakeups per operation and want to avoid lock internal lock contention
> by
On Fri, Nov 22, 2013 at 04:56:37PM -0800, Davidlohr Bueso wrote:
From: Peter Zijlstra pet...@infradead.org
Original patchset: https://lkml.org/lkml/2011/9/14/118
This is useful for locking primitives that can effect multiple
wakeups per operation and want to avoid lock internal lock
I used to have a patch to schedule() that would always immediately fall
through and only actually block on the second call; it illustrated the
problem really well, in fact so well the kernels fails to boot most
times.
I found the below on my filesystem -- making it apply shouldn't be hard.
On Sat, 2013-11-23 at 13:01 +0100, Peter Zijlstra wrote:
I used to have a patch to schedule() that would always immediately fall
through and only actually block on the second call; it illustrated the
problem really well, in fact so well the kernels fails to boot most
times.
I found the
From: Peter Zijlstra
Original patchset: https://lkml.org/lkml/2011/9/14/118
This is useful for locking primitives that can effect multiple
wakeups per operation and want to avoid lock internal lock contention
by delaying the wakeups until we've released the lock internal locks.
Alternatively
From: Peter Zijlstra pet...@infradead.org
Original patchset: https://lkml.org/lkml/2011/9/14/118
This is useful for locking primitives that can effect multiple
wakeups per operation and want to avoid lock internal lock contention
by delaying the wakeups until we've released the lock internal
8 matches
Mail list logo
