[Ocfs2-devel] [PATCH 0/3] ocfs2: Inode Allocation Strategy Improvement.v2

[Sunil Mushran]

:)

tristan.ye wrote:
> On Mon, 2009-01-19 at 10:35 -0800, Sunil Mushran wrote:
>   
>> Good numbers. Did you a 2nd rm -rf too? It should show the largest  
>> improvement of all.
>>     
>
> Yes, fairly cool, we also got up to 3 mins performance gain during 2nd
> rm -rf test:
>
> =============== Tests with 10 times iteration================
>  2nd 'rm -rf' result:
>
> Average real time with 10 times: 
> Original kernel                            kernel with enhanced patches
>  4m3.425ss                                      0m59.423ss
>
>
>
>
> Regards,
> Tristan
>
>   
>> On Jan 19, 2009, at 4:57 AM, "tristan.ye" <tristan.ye at oracle.com> wrote:
>>
>>     
>>> On Mon, 2009-01-19 at 15:15 +0800, Tao Ma wrote:
>>>       
>>>> tristan.ye wrote:
>>>>         
>>>>> On Sun, 2009-01-18 at 07:17 -0800, Sunil Mushran wrote:
>>>>>           
>>>>>> How big is this disk? Maybe one kernel tree untar is not be  
>>>>>> enough to
>>>>>> expose the original issue. Also, use ls -i and/or debugfs to see if
>>>>>> the inodes have some locality.
>>>>>>             
>>>>> Tao, sunil
>>>>>
>>>>> I've tested it out with more attempts, it may have something to do  
>>>>> with
>>>>> the disk size. but the root pause why i did not get a excited  
>>>>> speed-up
>>>>> performance gain was due to the iscsi-target(iscsi server) cache.  
>>>>> the
>>>>> operation in your testcase which was meant for cache dropping is  
>>>>> aimed
>>>>> at client side(a 'echo 2>/proc/sys/vm/drop_cache' only flush the  
>>>>> fs's
>>>>> cache for iscsi initor(isci client)).
>>>>>
>>>>> Tao,
>>>>>
>>>>> You can verify this by pausing the tests at the right point before  
>>>>> we
>>>>> start '2rd ls -lR', then flush the iscsi-target's cache by 'service
>>>>> iscsi-target restart'(there may be a more graceful way to do  
>>>>> this),after
>>>>> this done, resume the tests, then you'll find the the realtime it
>>>>> consumed will be up to 3 mins around:)
>>>>>           
>>>> cool, so I am very glad that you got the same result as mine. ;)
>>>>         
>>>>> Btw, i really saw lots of locality by 'ls -li' for inodes under a  
>>>>> same
>>>>> dir, take /mnt/ocfs2/linux-2.6.28/include/linux for instance,  
>>>>> almost all
>>>>> of its inodes are contiguous one by one regarding to its inode  
>>>>> number.
>>>>>           
>>>> yeah, that is the desired behaviour with my 3 patches. :)
>>>>
>>>> Then do you have any updated test statistics?
>>>>         
>>> Tao,
>>>
>>> With iscsi-target cache flushed everytime before tests getting  
>>> started,
>>> following is the updated testing result:
>>>
>>> Testing node:test7
>>> Testing volume: iscsi sdd1
>>>
>>> =============== Tests with 10 times iteration================
>>>
>>> 1st 'Tar xjvf' result:
>>>
>>> Average real time with 10 times:
>>> Original kernel                            kernel with enhanced  
>>> patches
>>> 0m 22.468s                                       0m 23.472s
>>>
>>> 1st 'ls -lR' result:
>>> Average real time with 10 times:
>>> Original kernel                            kernel with enhanced  
>>> patches
>>> 0m 30.682s                                        0m 30.414s
>>>
>>> 1st 'rm -rf' result:
>>> Average real time with 10 times:
>>> Original kernel                            kernel with enhanced  
>>> patches
>>> 0m 1m5.715s                                       0m 1m3.835s
>>>
>>> 2rd 'Tar xjvf' result:
>>> Average real time with 10 times:
>>> Original kernel                            kernel with enhanced  
>>> patches
>>> 0m 31.550s                                       0m 28.726s
>>>
>>> 2rd 'ls -lR' result:
>>> Average real time with 10 times:
>>> Original kernel                            kernel with enhanced  
>>> patches
>>>
>>> 0m 3m5.772s                                       0m 30.274s
>>>
>>> ===============Tests end============================
>>>
>>> Glad to see your guy's patch has greatly improved the performance of
>>> inodes traversing:),
>>>
>>> Unfortunately, the 1st Tar testcase still get a performance
>>> penality(around 1s) everytime.
>>>
>>> I've kept the testing env on test7 for your verification.
>>>
>>>
>>> Regards,
>>>
>>> Tristan
>>>
>>>       
>>>> Regards,
>>>> Tao
>>>>         
>
>