Re: Spin Lock sleep resolution

On 27.06.2013 17:30, Robert Haas wrote:
> On Wed, Jun 26, 2013 at 5:49 PM, Jeff Janes<jeff(dot)janes(at)gmail(dot)com> wrote:
>> If we think the patch has a risk of introducing subtle errors, then it
>> probably can't be justified based on the small performance gains you saw.
>>
>> But if we think it has little risk, then I think it is justified simply
>> based on cleaner code, and less confusion for people who are tracing a
>> problematic process. If we want it to do a random escalation, it should
>> probably look like a random escalation to the interested observer.
>
> I think it has little risk. If it turns out to be worse for
> performance, we can always revert it, but I expect it'll be better or
> a wash, and the results so far seem to bear that out. Another
> interesting question is whether we should fool with the actual values
> for minimum and maximum delays, but that's a separate and much harder
> question, so I think we should just do this for now and call it good.

My thoughts exactly. I wanted to see if David Gould would like to do
some testing with it, but there's realy no need to hold off committing
for that, I'm not expecting any surprises there. Committed.

Jeff, in the patch you changed the datatype of cur_delay variable from
int to long. AFAICS that makes no difference, so I kept it as int. Let
me know if there was a reason for that change.

- Heikki