Re: [patch] zfs livelock and thread priorities

2009/5/19 Ben Kelly <ben_at_wanderview.com>:
> On May 18, 2009, at 1:38 PM, Attilio Rao wrote:
>>
>> OMG.
>> This still doesn't explain priorities like 49 or such seen in the
>> first report as long as we don't set priorities by hand,
>
> I'm trying to understand why this particular priority value is so
> concerning, but I'm a little bit confused.  Can you elaborate on why you
> think its a problem?  From previous off-list e-mails I get the impression
> that you are concerned that it does not fall on an RQ_PPQ boundary.  Is this
> the case?  Again, I may be completely confused, but ULE does not seem to
> consider RQ_PPQ when it assigns priorities for interactive threads.  Here is
> how I came to this conclusion:

I'm concerned because the first starvation I saw in this thread was
caused by the proprity lowered inappropriately (it was 49 on 45 IIRC).
49 means that the thread will never be choosen when the 45s are still
in the runqueue. I'm not concerned on RQ_PPQ boundaries.

> From what I can tell a thread's priority might be adjusted for interactivity
> in sched_priority() around line 1421 of sched_ule:
>
>>        score = imax(0, sched_interact_score(td) - td->td_proc->p_nice);
>>        if (score < sched_interact) {
>>                pri = PRI_MIN_REALTIME;
>>                pri += ((PRI_MAX_REALTIME - PRI_MIN_REALTIME) /
>> sched_interact)
>>                    * score;
>
> One my machine (PRI_MAX_REALTIME - PRI_MIN_REALTIME) / sched_interact
> resolves to a value of 1.  So the priority is being set to PRI_MIN_REALTIME
> plus the value of score.  According to the comment on sched_interact_score()
> the returned value ranges from 0 to 100.  As far as I can tell from looking
> at the code the calculations based on the ration of ts_runtime to
> ts_sleeptime aren't guaranteed to return a value divisible by RQ_PPQ.  For
> example, on my machine tickincr turns out to be 8000.  So if ts_sleeptime is
> 16000 and ts_runtime is 8000 sched_interact_score() will return a value of
> 25.  Which then means the thread will be assigned a priority of
> PRI_MIN_REALTIME + 25.
>
> Also, looking at my currently idle system I actually have many priorities
> that do not fall on RQ_PPQ boundaries:
>
>> ianto# ps ax -opri | grep 43 | wc -l
>>      14
>> ianto# ps ax -opri | grep 44 | wc -l
>>      70
>> ianto# ps ax -opri | grep 45 | wc -l
>>       4
>> ianto# ps ax -opri | grep 46 | wc -l
>>       3
>> ianto# ps ax -opri | grep 47 | wc -l
>>       2
>> ianto# ps ax -opri | grep 48 | wc -l
>>       1
>> ianto# ps ax -opri | grep 49 | wc -l
>>       1
>
> I'm running a non-SMP kernel with ULE last synced with subversion on March
> 16.   Full system info can be found here:
>
>  http://www.wanderview.com/svn/public/misc/zfs_livelock/
>
> Anyway, I apologize if I'm missing something.  I'd be happy to do more
> investigation if you'd like.  Just let me know.

I still need to check the ktr/datas you sent me that time, I just need
to find the time to do that, sorry.

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein