search for: fadvise

..., Ravishankar N wrote: > > > On 08/11/2017 04:51 PM, Niels de Vos wrote: > > On Fri, Aug 11, 2017 at 12:47:47AM -0400, Raghavendra Gowdappa wrote: > > > Hi all, > > > > > > In a conversation between me, Milind and Csaba, Milind pointed out > > > fadvise(2) [1] and its potential benefits to Glusterfs' caching > > > translators like read-ahead etc. After discussing about it, we agreed > > > that our performance translators can leverage the hints to provide > > > better performance. Now the question is how commonly appl...

...s working on a large directory it can quickly fill the page cache with written data, displacing the rest of the system's working set. The solution for this is to inform the kernel that our written pages will no longer be needed and should be expelled to disk. The POSIX interface for this, posix_fadvise, has existed for some time, but there has been no useable implementation in any of the major operating systems. Attempts have been made in the past[1] to use the fadvise interface, but kernel limitations have made this quite messy. In particular, the kernel supports FADV_DONTNEED as a single-shot...

On Fri, Aug 11, 2017 at 12:47:47AM -0400, Raghavendra Gowdappa wrote: > Hi all, > > In a conversation between me, Milind and Csaba, Milind pointed out > fadvise(2) [1] and its potential benefits to Glusterfs' caching > translators like read-ahead etc. After discussing about it, we agreed > that our performance translators can leverage the hints to provide > better performance. Now the question is how commonly applications > actually provide...

On 08/11/2017 04:51 PM, Niels de Vos wrote: > On Fri, Aug 11, 2017 at 12:47:47AM -0400, Raghavendra Gowdappa wrote: >> Hi all, >> >> In a conversation between me, Milind and Csaba, Milind pointed out >> fadvise(2) [1] and its potential benefits to Glusterfs' caching >> translators like read-ahead etc. After discussing about it, we agreed >> that our performance translators can leverage the hints to provide >> better performance. Now the question is how commonly applications >>...

Hi Niels, On Fri, Aug 11, 2017 at 2:33 PM, Niels de Vos <ndevos at redhat.com> wrote: > On Fri, Aug 11, 2017 at 05:50:47PM +0530, Ravishankar N wrote: [...] >> To me it looks like fadvise (mm/fadvise.c) affects only the linux page cache >> behavior and is decoupled from the filesystem itself. What this means for >> fuse is that the 'advise' is only to the content that the fuse kernel >> module has stored in that machine's page cache. Exposing it as a...

...t, Aug 19, 2017 at 4:27 PM, Csaba Henk <chenk at redhat.com> wrote: > Hi Niels, > > On Fri, Aug 11, 2017 at 2:33 PM, Niels de Vos <ndevos at redhat.com> wrote: > > On Fri, Aug 11, 2017 at 05:50:47PM +0530, Ravishankar N wrote: > [...] > >> To me it looks like fadvise (mm/fadvise.c) affects only the linux page > cache > >> behavior and is decoupled from the filesystem itself. What this means > for > >> fuse is that the 'advise' is only to the content that the fuse kernel > >> module has stored in that machine's page...

...tly 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 not use fadvise to notify the kernel of its use-once data usage pattern. It looks like a patch[1] was written (although never merged, it seems) incorporating fadvise support, but I found its implementation rather odd, using mincore() and FADV_DONTNEED to kick out only regions brought in by rsync. It seemed to me...

...total used free shared buff/cache available Mem: 32083 1190 313 1 30578 30433 Swap: 16135 16 16119 pages in cache: 7053276/8388608 (84.1%) [filesize=33554432.0K, pagesize=4K] Now we repeat the test using fadvise=sequential cache=none: $ cachedel /var/tmp/random $ cachestats /var/tmp/random pages in cache: 106/8388608 (0.0%) [filesize=33554432.0K, pagesize=4K] $ free -m; time ./nbdkit file /var/tmp/random fadvise=sequential cache=none --run 'qemu-img convert -n -p -m 16 -W $nbd "json:{\"fil...

Hi all, In a conversation between me, Milind and Csaba, Milind pointed out fadvise(2) [1] and its potential benefits to Glusterfs' caching translators like read-ahead etc. After discussing about it, we agreed that our performance translators can leverage the hints to provide better performance. Now the question is how commonly applications actually provide hints? Is it someth...

Hi List, I have updated my rsync fadvise patch which stops rsync from ousting all your other data from cache when running large jobs. I have also written an article about the whole issue. http://insights.oetiker.ch/linux/fadvise.html cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten http://it.oetiker.ch tobi@oe...

On Fri, Aug 7, 2020, 16:16 Richard W.M. Jones <rjones@redhat.com> wrote: > On Fri, Aug 07, 2020 at 07:53:13AM -0500, Eric Blake wrote: > > >$ free -m; time ./nbdkit file /var/tmp/random fadvise=sequential > cache=none --run 'qemu-img convert -n -p -m 16 -W $nbd > "json:{\"file.driver\":\"null-co\",\"file.size\":\"1E\"}"' ; free -m ; > cachestats /var/tmp/random > > > > Hmm - the -W actually says that qemu-img i...

On Fri, Aug 07, 2020 at 07:53:13AM -0500, Eric Blake wrote: > >$ free -m; time ./nbdkit file /var/tmp/random fadvise=sequential cache=none --run 'qemu-img convert -n -p -m 16 -W $nbd "json:{\"file.driver\":\"null-co\",\"file.size\":\"1E\"}"' ; free -m ; cachestats /var/tmp/random > > Hmm - the -W actually says that qemu-img is performing semi-random...

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 server after backup as executable pages were being swapped out in favor of data waiting to be flushed to disk. This is an extremely poor trade-off in the case of a backup but the user-mode had no way to commun...

...free shared buff/cache available > Mem: 32083 1190 313 1 30578 30433 > Swap: 16135 16 16119 > pages in cache: 7053276/8388608 (84.1%) [filesize=33554432.0K, pagesize=4K] > > Now we repeat the test using fadvise=sequential cache=none: > > $ cachedel /var/tmp/random > $ cachestats /var/tmp/random > pages in cache: 106/8388608 (0.0%) [filesize=33554432.0K, pagesize=4K] > > $ free -m; time ./nbdkit file /var/tmp/random fadvise=sequential cache=none --run 'qemu-img convert -n -p -m 16...

...ugin.pod | 19 +++++++++++++------ tests/test-gzip.c | 2 +- 3 files changed, 25 insertions(+), 18 deletions(-) diff --git a/plugins/file/file.c b/plugins/file/file.c index f6f91955..deac9b7f 100644 --- a/plugins/file/file.c +++ b/plugins/file/file.c @@ -76,7 +76,7 @@ static int fadvise_mode = ; /* cache mode */ -static enum { cache_default, cache_none } cache_mode = cache_default; +static enum { cache_writeback, cache_writethrough } cache_mode = cache_writeback; /* Any callbacks using lseek must be protected by this lock. */ static pthread_mutex_t lseek_lock = PTHREAD_M...

On Fri, Aug 7, 2020 at 5:36 PM Richard W.M. Jones <rjones@redhat.com> wrote: > > On Fri, Aug 07, 2020 at 05:29:24PM +0300, Nir Soffer wrote: > > On Fri, Aug 7, 2020 at 5:07 PM Richard W.M. Jones <rjones@redhat.com> wrote: > > > These ones? > > > https://www.redhat.com/archives/libguestfs/2020-August/msg00078.html > > > > No, we had a bug when

Take 2... this version only adds code to discard the cache on Linux and uses the right name for the fadvise call. It''s a bit ugly - I basically just put #ifdef __linux__ around the fadvise calls - but I don''t have the ability to develop something suitable for Solaris... > Attached is a patch to unstable that stops save/restore/dump from > hosing > Dom0 when dealing with large...

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/11/21/59 --- syscall.c | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-) di...

...tests/test-gzip.c | 2 +- > 3 files changed, 25 insertions(+), 18 deletions(-) > > diff --git a/plugins/file/file.c b/plugins/file/file.c > index f6f91955..deac9b7f 100644 > --- a/plugins/file/file.c > +++ b/plugins/file/file.c > @@ -76,7 +76,7 @@ static int fadvise_mode = > ; > > /* cache mode */ > -static enum { cache_default, cache_none } cache_mode = cache_default; > +static enum { cache_writeback, cache_writethrough } cache_mode = cache_writeback; > > /* Any callbacks using lseek must be protected by this lock. */ > stati...

...t; > > > > > > Yes, don't call it none if you use the cache. > > > > How about advise=? > > > > I would keep cache semantics similar to qemu. > > qemu uses cache=none as a synonym for O_DIRECT, but AFAIK it has > nothing that tries to use posix_fadvise(DONTNEED) with or without > Linus's double buffering technique. Yes, this is the right way. posix_fadvise is not a replacement for O_DIRECT. > qemu does use > posix_fadvise(DONTNEED) in one place but AFAICT it is only used for > live migration. > > ... > > We already t...