Re: 2.6.19-rc5-mm1 progression

[Larry Finger <Larry.Finger@lwfinger.net>]

Peter Zijlstra wrote:
> On Mon, 2006-12-04 at 21:32 -0600, Larry Finger wrote:
>> Andrew Morton wrote:
>>> On Fri, 24 Nov 2006 17:36:27 +0100
>>> "Benoit Boissinot" <bboissin@gmail.com> wrote:
>>>
>>>> On 11/24/06, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>>>>> Is there the equivalent of 'git bisect' for the -mmX kernels?
>>>>>
>>>> http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt
>>>>
>>> Please take the time to do that.  Yours is an interesting report - I'm not
>>> aware of anything in there which was expected to cause a change of this
>>> mature.
>>>
>> There are at least two patches in 2.6.19-rc5-mm2 that make my system much more responsive for 
>> interactive jobs. The one that has the majority of the effect is:
>>
>> radix-tree-rcu-lockless-readside.patch
>>
>> I have not been able to isolate the second patch, which has the lesser effect. All I can say is that 
>> it occurred before the above patch in patches/series. This patch was tested against 2.6.19 and fixed 
>> most of the problem on that version.
> 
> Curious...
> 
> This patch introduces the direct pointer optimisation for single element
> radix trees and makes the radix tree safe to read in a lock-less manner
> which is not used -yet-. The only difference that that should have is
> that the elements are freed using rcu callback instead of directly.
> 
> /me puzzled how this has a large effect on interactivity.

I also wondered why this patch should have the effect as it didn't seem in an area that should be 
important. I did test it on both 2.6.19-rc5-mm2 and vanilla 2.6.19. In both cases, it made 
interactive response improve.

One single task that seems to have the biggest effect on my unpatched systems is the link step for a 
new kernel. I am assuming that this process calls for lots of virtual memory. One other 
characteristic of my system when it gets unresponsive is that kswapd is running regularly; however, 
I have never observed any swap file usage.

Larry