John Baldwin wrote:
>On 18-Oct-01 Alexander Langer wrote:
>
>>Thus spake Alex Levine ([EMAIL PROTECTED]):
>>
>>>resetpriority() calls maybe_resched() at the end after updating p_usrpri
>>>based on changed p_estcpu.
>>>maybe_resched() uses curpriority_cmp to compare priorities of current
>>>and given process and this function ( curpriority_cmp ) uses p_priority
>>>which is unchanged yet - the new p_usrpri is not reflected to p_priority
>>>yet.
>>>
>>In -CURRENT, it's more obvious:
>>maybe_resched() only rescheds, if the resetted process' priority
>>level changes.
>>
>>Since resetpriority() doesn't modify the priority level but
>>only the user priority, the call to maybe_resched() has no
>>effect at all -- only some overhead for the comparisons
>>(curproc will have had the higher or same priority level
>>as the resetted process anyways, otherwise it hadn't been curproc :)
>>
>>So, either
>> - p's priority level in resetpriority has to be re-calculted
>> as well, or
>> - the call to maybe_resched() can be removed w/o loss
>> of functionality.
>>
>
>
>or c) in the preemptive kernel maybe_resched() doesn't exist as it's
>functionality is more properly handled in other places.
>
I took another look in CURRENT. The same call to maybe_resched from
reset_priority is as useless as in STABLE. Only there the recalculation
relies on pri_level, which replaced p_priority as I understand but the
thing which is being changed is usr_pri. So it's the same.
Regards, Alex Levine
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
