Re: FADV_DONTNEED support

Ben Gamari writes: > While going through an old todo list I found that these patches had fallen by > the way-side. About a year ago I initiated a discussion[1] with the Linux > kernel folks regarding the lack of any useable fadvise support on the kernel > side. As a result, I w

[PATCH 3/3] Inform kernel of FADV_DONTNEED hint in receiver

Use the FADV_DONTNEED fadvise hint after finishing writing to a destinataion fd in the receiver. --- receiver.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/receiver.c b/receiver.c index d90fa25..b151cf8 100644 --- a/receiver.c +++ b/receiver.c @@ -742,6 +742,12 @@

[PATCH 2/3] Inform kernel of FADV_DONTNEED hint in sender

Use the FADV_DONTNEED fadvise hint after finishing reading an origin fd in the sender. --- sender.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/sender.c b/sender.c index 59dae7d..e442933 100644 --- a/sender.c +++ b/sender.c @@ -338,6 +338,12 @@ void send_files(int

[PATCH 1/3] Add fadvise interface wrapper

With recent discussion on the LKML[1], it seems likely that Linux will finally support posix_fadvise in a useful way with the FADV_DONTNEED flag. This should allow us to minimize the effect of rsync on the system's working set. Add the necessary wrapper to syscall.c. [1] http://lkml.org/lkml/2010/

FADV_DONTNEED support

While going through an old todo list I found that these patches had fallen by the way-side. About a year ago I initiated a discussion[1] with the Linux kernel folks regarding the lack of any useable fadvise support on the kernel side. As a result, I was observing extremely poor performance on my se

[PATCH 3/3] Inform kernel of FADV_DONTNEED hint in receiver

Use the FADV_DONTNEED fadvise hint after finishing writing to a destinataion fd in the receiver. --- receiver.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/receiver.c b/receiver.c index 39c5e49..33b21fb 100644 --- a/receiver.c +++ b/receiver.c @@ -721,6 +721,12 @@

[PATCH 2/3] Inform kernel of FADV_DONTNEED hint in sender

Use the FADV_DONTNEED fadvise hint after finishing reading an origin fd in the sender. --- sender.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/sender.c b/sender.c index 59dae7d..a934bfe 100644 --- a/sender.c +++ b/sender.c @@ -338,6 +338,12 @@ void send_files(int

[PATCH 1/3] Add fadvise interface wrapper

With recent discussion on the LKML[1], it seems likely that Linux will finally support posix_fadvise in a useful way with the FADV_DONTNEED flag. This should allow us to minimize the effect of rsync on the system's working set. Add the necessary wrapper to syscall.c. [1] http://lkml.org/lkml/2010/

[RFC PATCH] fadvise support in rsync

first post and disable this unbelievably counterproductive "feature"? Thanks! Cheers, - Ben On Tue, 23 Nov 2010 09:49:49 -0500, Ben Gamari wrote: > > Warning for kernel folks: I'm not much of an mm person; let me know if I got > anything horribly wrong. > > Many fo

[RFC PATCH] fadvise support in rsync

Warning for kernel folks: I'm not much of an mm person; let me know if I got anything horribly wrong. Many folks use rsync in their nightly backup jobs. In these applications, speed is of minimal concern and should be sacrificed in order to minimize the effect of rsync on the rest of the machine.

Re: fadvise DONTNEED implementation (or lack thereof)

On Mon, 15 Nov 2010 16:28:32 +0900 (JST), KOSAKI Motohiro wrote: > Who can make rsync like io pattern test suite? a code change is easy. but > to comfirm justification is more harder work. > I'm afraid I don't have time to work up any code. I would be happy to try the patch with my backup use-ca

Re: fadvise DONTNEED implementation (or lack thereof)

On Sun, 14 Nov 2010 14:09:29 +0900 (JST), KOSAKI Motohiro wrote: > Because we have an alternative solution already. please try memcgroup :) > Alright, fair enough. It still seems like there are many cases where fadvise seems more appropriate, but memcg should at least satisfy my personal needs s

Re: fadvise DONTNEED implementation (or lack thereof)

On Tue, 9 Nov 2010 16:28:02 +0900 (JST), KOSAKI Motohiro wrote: > So, I don't think application developers will use fadvise() aggressively > because we don't have a cross platform agreement of a fadvice behavior. > I strongly disagree. For a long time I have been trying to resolve interactivity

fadvise DONTNEED implementation (or lack thereof)

I've recently been trying to track down the root cause of my server's persistent issue of thrashing horribly after being left inactive. It seems that the issue is likely my nightly backup schedule (using rsync) which traverses my entire 50GB home directory. I was surprised to find that rsync does n