On Tue, 23 Nov 2010 16:16:55 +0900 (JST), KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx> wrote: > > On Sun, 21 Nov 2010 23:30:23 +0900, Minchan Kim <minchan.kim@xxxxxxxxx> wrote: > > > > > > Ben, Remain thing is to modify rsync and use > > > fadvise(POSIX_FADV_DONTNEED). Could you test it? > > > > Thanks a ton for the patch. Looks good. Testing as we speak. > For the record, this was a little premature. As I spoke the kernel was building but I still haven't had a chance to take any data. Any suggestions for how to determine the effect (or hopefully lack thereof) of rsync on the system's working set? > If possible, can you please post your rsync patch and your testcase > (or your rsync option + system memory size info + data size info)? > Patch coming right up. The original test case is a backup script for my home directory. rsync is invoked with, rsync --archive --update --progress --delete --delete-excluded --exclude-from=~/.backup/exclude --log-file=~/.backup/rsync.log -e ssh /home/ben ben@myserver:/mnt/backup/current My home directory is 120 GB with typical delta sizes of tens of megabytes between backups (although sometimes deltas can be gigabytes, after which the server has severe interactivity issues). The server is unfortunately quite memory constrained with only 1.5GB of memory (old inherited hardware). Given the size of my typical deltas, I'm worried that even simply walking the directory hierarchy might be enough to push out my working set. Looking at the rsync access pattern with strace it seems that it does a very good job of avoid duplicate reads which is good news for these patches. Cheers, - Ben -- 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>