On Thu, Nov 08, 2012 at 04:51:11AM -0800, Linda Walsh wrote: > 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. It's not xfs_fsr that is causing this problem. It's other applications, I think, generating memory pressure and xfs_fsr is the unfortunate victim... > 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... posix_fadvise won't affect fsr at all, because: int openopts = O_CREAT|O_EXCL|O_RDWR|O_DIRECT; it uses direct IO, and hence bypasses the page cache. posix_fadvise only affects buffered IO behaviour (i.e. via the page cache), and hence will have no effect on IO issued by xfs_fsr. > It doesn't increase or decrease the memory usage, just makes alloc'ing and > freeing it in the kernel a bit smoother... I'd say that's a subjective observation rather than an empirical one - you're expecting it to improve, so you think it did. ;) > Maybe other utils might benefit as well, dunno, ...but fsr was the most > obvious to see the changes with. Most of the XFS tools that do significant IO use direct IO, so it's unlikely to make much measurable difference to tool behaviour... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
