I was looking at output of xosview and watched a daily run of xfs_fsr take
off as normal, and do it's normal thing of allocating remaining buffer
memory during it's run -- and, as seems normal, it would go up to the
machine's limit, then the kernel's memory reclaiming would kick in for a few
hundred ms, and take memory usage down from 48G to maybe 30+G.
During this time, I'd see xfs_fsr stop or pause for a bit, then resume and
I'd see a used-buffer memory look like slow ramps followed by sharp drops
with xfs_fsr showing i/o gaps as the ramps peaked.
I wondered why it lumped all this memory reclaiming and thought to try using
the posix_fadvise calls in xfs_fsr to tell the kernel what data was unneeded
and such...
It seems to have increased overall perf, and there doesn't seem to be
anymore contention or I/O drops... no more ramping either ... it goes to the
top and stays there, with the free-memory process keeping pace with fsr's
usage.
If it doesn't look like it would cause problems (seems to reduce memory
manager thrashing), maybe you'd like to add the patch to the source tree?
It's *WAY* trivial:
-------------------------
--- fsr/xfs_fsr.c 2011-02-11 02:42:15.000000000 -0800
+++ fsr/xfs_fsr.c 2012-11-08 04:10:18.608718948 -0800
@@ -1163,6 +1163,10 @@
}
unlink(tname);
+ posix_fadvise(fd, 0, 0, POSIX_FADV_NOREUSE|POSIX_FADV_SEQUENTIAL);
+
+ posix_fadvise(tfd, 0, 0, POSIX_FADV_DONTNEED);
+
/* Setup extended attributes */
if (fsr_setup_attr_fork(fd, tfd, statp) != 0) {
fsrprintf(_("failed to set ATTR fork on tmp: %s:\n"), tname);
-------
That's it... set the input files for sequential access and no-reuse after
the read, and set the output descriptor to tell the kernel I won't need the
data that will be going into it.
It hasn't been **extensively*** tested... just plopped it in and it seems to
have good behavior... but it's simple enough and advisory, so the risk
should be minimal...(besides short-term testing showing it to be
beneficial)...
It doesn't increase or decrease the memory usage, just makes alloc'ing and
freeing it in the kernel a bit smoother...
hope you find it useful?
Maybe other utils might benefit as well, dunno, ...but fsr was the most
obvious to see the changes with.
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
