On Tue, 14 Dec 2010 00:31:05 +0900 Minchan Kim <minchan.kim@xxxxxxxxx> wrote: > Test Environment : > DRAM : 2G, CPU : Intel(R) Core(TM)2 CPU > Rsync backup directory size : 16G > > rsync version is 3.0.7. > rsync patch is Ben's fadivse. > stress scenario do following jobs with parallel. > > 1. make all -j4 linux, git clone linux-kernel > 2. git clone linux-kernel > 3. rsync src dst > > nrns : no-patched rsync + no stress > prns : patched rsync + no stress > nrs : no-patched rsync + stress > prs : patched rsync + stress > > pginvalidate : the number of dirty/writeback pages which is invalidated by fadvise > pgreclaim : pages moved PG_reclaim trick in inactive's tail > > In summary, my patch enhances a littie bit about elapsed time in > memory pressure environment and enhance reclaim effectivness(reclaim/reclaim) > with x2. It means reclaim latency is short and doesn't evict working set > pages due to invalidated pages. > > Look at reclaim effectivness. Patched rsync enhances x2 about reclaim > effectiveness and compared to mmotm-12-03, mmotm-12-03-fadvise enhances > 3 minute about elapsed time in stress environment. > I think it's due to reduce scanning, reclaim overhead. > > In no-stress enviroment, fadivse makes program little bit slow. > I think because there are many pgfault. I don't know why it happens. > Could you guess why it happens? > > Before futher work, I hope listen opinions. > Any comment is welcome. > At first, the improvement seems great. Thank you for your effort. > In no-stress enviroment, fadivse makes program little bit slow. > I think because there are many pgfault. I don't know why it happens. > Could you guess why it happens? > Are there no program which accesses a directory rsync'ed ? Thanks, -Kame -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>