On Tue, Sep 11, 2018 at 12:21:22PM -0700, Davidlohr Bueso wrote:
> On Mon, 10 Sep 2018, Peter Zijlstra wrote:
>
> > [ RT has something along those lines, and I have half a patch that
> > starts doing that too, but I never found enough time to really work on
> > it :-( ]
>
> But don't rt rwsems
On Tue, Sep 11, 2018 at 12:21:22PM -0700, Davidlohr Bueso wrote:
> On Mon, 10 Sep 2018, Peter Zijlstra wrote:
>
> > [ RT has something along those lines, and I have half a patch that
> > starts doing that too, but I never found enough time to really work on
> > it :-( ]
>
> But don't rt rwsems
On Mon, 10 Sep 2018, Peter Zijlstra wrote:
[ RT has something along those lines, and I have half a patch that
starts doing that too, but I never found enough time to really work on
it :-( ]
But don't rt rwsems act pretty much like a regular mutex in that it only
allows readers to nest, not
On Mon, 10 Sep 2018, Peter Zijlstra wrote:
[ RT has something along those lines, and I have half a patch that
starts doing that too, but I never found enough time to really work on
it :-( ]
But don't rt rwsems act pretty much like a regular mutex in that it only
allows readers to nest, not
On 09/11/2018 04:17 AM, Peter Zijlstra wrote:
> On Mon, Sep 10, 2018 at 10:15:50AM -0700, Davidlohr Bueso wrote:
>> On Mon, 10 Sep 2018, Waiman Long wrote:
>>
>>> One major issue with a combined count/owner is that we may have to use
>>> cmpxchg for reader lock which will certainly impact
On 09/11/2018 04:17 AM, Peter Zijlstra wrote:
> On Mon, Sep 10, 2018 at 10:15:50AM -0700, Davidlohr Bueso wrote:
>> On Mon, 10 Sep 2018, Waiman Long wrote:
>>
>>> One major issue with a combined count/owner is that we may have to use
>>> cmpxchg for reader lock which will certainly impact
On Mon, Sep 10, 2018 at 10:15:50AM -0700, Davidlohr Bueso wrote:
> On Mon, 10 Sep 2018, Waiman Long wrote:
>
> > One major issue with a combined count/owner is that we may have to use
> > cmpxchg for reader lock which will certainly impact reader-heavy
> > workloads. I have also thought about
On Mon, Sep 10, 2018 at 10:15:50AM -0700, Davidlohr Bueso wrote:
> On Mon, 10 Sep 2018, Waiman Long wrote:
>
> > One major issue with a combined count/owner is that we may have to use
> > cmpxchg for reader lock which will certainly impact reader-heavy
> > workloads. I have also thought about
On 09/10/2018 01:15 PM, Davidlohr Bueso wrote:
> On Mon, 10 Sep 2018, Waiman Long wrote:
>
>> One major issue with a combined count/owner is that we may have to use
>> cmpxchg for reader lock which will certainly impact reader-heavy
>> workloads. I have also thought about ways to compress the task
On 09/10/2018 01:15 PM, Davidlohr Bueso wrote:
> On Mon, 10 Sep 2018, Waiman Long wrote:
>
>> One major issue with a combined count/owner is that we may have to use
>> cmpxchg for reader lock which will certainly impact reader-heavy
>> workloads. I have also thought about ways to compress the task
On Mon, 10 Sep 2018, Waiman Long wrote:
One major issue with a combined count/owner is that we may have to use
cmpxchg for reader lock which will certainly impact reader-heavy
workloads. I have also thought about ways to compress the task pointer
address so that it can use fewer bits and leave
On Mon, 10 Sep 2018, Waiman Long wrote:
One major issue with a combined count/owner is that we may have to use
cmpxchg for reader lock which will certainly impact reader-heavy
workloads. I have also thought about ways to compress the task pointer
address so that it can use fewer bits and leave
On 09/10/2018 05:31 AM, Peter Zijlstra wrote:
> On Thu, Sep 06, 2018 at 04:18:34PM -0400, Waiman Long wrote:
>> Currently, when a reader acquires a lock, it only sets the
>> RWSEM_READER_OWNED bit in the owner field. The other bits are simply
>> not used. When debugging hanging cases involving
On 09/10/2018 05:31 AM, Peter Zijlstra wrote:
> On Thu, Sep 06, 2018 at 04:18:34PM -0400, Waiman Long wrote:
>> Currently, when a reader acquires a lock, it only sets the
>> RWSEM_READER_OWNED bit in the owner field. The other bits are simply
>> not used. When debugging hanging cases involving
On Thu, Sep 06, 2018 at 04:18:34PM -0400, Waiman Long wrote:
> Currently, when a reader acquires a lock, it only sets the
> RWSEM_READER_OWNED bit in the owner field. The other bits are simply
> not used. When debugging hanging cases involving rwsems and readers,
> the owner value does not provide
On Thu, Sep 06, 2018 at 04:18:34PM -0400, Waiman Long wrote:
> Currently, when a reader acquires a lock, it only sets the
> RWSEM_READER_OWNED bit in the owner field. The other bits are simply
> not used. When debugging hanging cases involving rwsems and readers,
> the owner value does not provide
Currently, when a reader acquires a lock, it only sets the
RWSEM_READER_OWNED bit in the owner field. The other bits are simply
not used. When debugging hanging cases involving rwsems and readers,
the owner value does not provide much useful information at all.
This patch modifies the current
Currently, when a reader acquires a lock, it only sets the
RWSEM_READER_OWNED bit in the owner field. The other bits are simply
not used. When debugging hanging cases involving rwsems and readers,
the owner value does not provide much useful information at all.
This patch modifies the current
18 matches
Mail list logo
