Tuning SYSVR3 (Esix Rev D) (LONG!)

[Andy Glew]

>>->>Even if you set this variable to some high value, it is still possible 
>>->>that at that new time period following a large disk update, the system 
>>->>will slow down momentarily due to many dirty pages that still need to 
>>->>be written out, so you may be in a no-win situation.
>> 
>There was some considerable discussion about this maybe two years ago
>with regards to the Motorola UNIX product. Their version used a linear
>search to scan for dirty buffers, which worked well until the total
>buffer cache exceeded 2 MB, then things would periodically get very
>slow. I don't know if this was pre- or post- bdflush.

Urghh.  This was fixed while I was at Motorola MCD (not by me, but by
a guy working with me -- I'd give him credit, but announcing his name
on the net would probably lead to calls from the field that are better
handled by customer service -- hi, anyway, Eric!)

Motorola UNIX now has a segmented buffer cache scanning algorithm -
you define the time period that the whole buffer is to be scanned in,
and the maximum number of buffers to be scanned in any step.

The effect on the variance of interactive response time was dramatic.
I measured it.

--
Andy Glew, a-glew at uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]