On Mon, May 18, 2009 at 07:03:45PM -0700, Kip Macy wrote: > Thanks, I appreciate all this work. ?Not allowing inactive pages to > shrink the ARC sounds great as an option. ?I would be willing to bet > that allowing inactive pages to shrink the arc would be far less > detrimental to most people who aren't running a constant busy file > server load, and its definitely important to try to protect untuned > boxes. Allowing NFS to use ARC buffers might be one solution to that. That would be interesting. I haven't used ZFS for any NFS serving yet though. With my mix of userspace file serving daemons my Inactive mem just rises 1-3M/sec until almost all free memory is consumed and I don't know why. None of the processes in top or ps can account for 16G of Inactive. > Do you have any suggestions for increasing the amount of memory ARC > can use? ?I've had difficulty increasing kmem past a few gigs on any > of my recent builds (all past where kmem was changed so it could be > more than ~2g) because at some point the kernel would stop booting. > If I increase them too far, a few lines of the booting kernel would > print, followed by a long stream of page fault panics or something > with a sudden reboot. ?With the recent change allowing the use of > direct mem, the ARC could easily use ample memory except it turned > out not to be stable. As of r192216 that should not be a probably any more. The maximum kmem is now 512GB. It will be at least a year or two before anyone bumps his head against that. Ahh oops, I mistakenly thought it was backed out a few minutes ago but that was something else. I guess that gives me something else I can test. A number of changes went in recently and it was hard to tell which commits were causing which symptoms.Received on Tue May 19 2009 - 00:16:05 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:47 UTC