On 08/16/2017 03:14 PM, Steven Rostedt wrote:
> On Wed, 16 Aug 2017 15:07:25 -0400
> Waiman Long wrote:
>
>
>> I am thinking about maybe letting a RT task to sleep a tiny amount of
>> time instead of calling schedule(). Hopefully, that will allow a
>> lower-priority task to make forward progress.
On Wed, 16 Aug 2017 15:07:25 -0400
Waiman Long wrote:
> I am thinking about maybe letting a RT task to sleep a tiny amount of
> time instead of calling schedule(). Hopefully, that will allow a
> lower-priority task to make forward progress.
That is actually one of the ugly hacks we have in the
On 08/16/2017 02:59 PM, Steven Rostedt wrote:
> On Wed, 16 Aug 2017 14:46:42 -0400
> Waiman Long wrote:
>
>
>> I haven't been thinking about RT tasks. You are right that it can be a
>> problem in this case. I think I will have to revert back to use
>> mutex_lock() if a RT task is running. Though i
On Wed, 16 Aug 2017 14:46:42 -0400
Waiman Long wrote:
> I haven't been thinking about RT tasks. You are right that it can be a
> problem in this case. I think I will have to revert back to use
> mutex_lock() if a RT task is running. Though in this case, the lock
> inversion problem will still be
On 08/16/2017 02:17 PM, Steven Rostedt wrote:
> On Wed, 16 Aug 2017 14:14:36 -0400
> Waiman Long wrote:
>
>>> You also just turned the mutex into a spinlock. What happens if we just
>>> preempted the owner of bdev->bd_mutex and are an RT task with higher
>>> priority? This will turn into a live lo
On Wed, 16 Aug 2017 14:14:36 -0400
Waiman Long wrote:
> > You also just turned the mutex into a spinlock. What happens if we just
> > preempted the owner of bdev->bd_mutex and are an RT task with higher
> > priority? This will turn into a live lock.
> >
> >> + schedule();
> >> + }
> >
On 08/15/2017 07:11 PM, Steven Rostedt wrote:
> On Thu, 10 Aug 2017 13:02:33 -0400
> Waiman Long wrote:
>
>> The lockdep code had reported the following unsafe locking scenario:
>>
>>CPU0CPU1
>>
>> lock(s_active#228);
>>
On Thu, 10 Aug 2017 13:02:33 -0400
Waiman Long wrote:
> The lockdep code had reported the following unsafe locking scenario:
>
>CPU0CPU1
>
> lock(s_active#228);
>lock(&bdev->bd_mutex/1);
>
The lockdep code had reported the following unsafe locking scenario:
CPU0CPU1
lock(s_active#228);
lock(&bdev->bd_mutex/1);
lock(s_active#228);
lock(&bdev->bd_mutex);
*
9 matches
Mail list logo