Date: Mon, 4 Mar 1996 18:34:09 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: davidg@Root.COM Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, monboso@masternet.it, freebsd-hackers@FreeBSD.ORG Subject: Re: xfs not working properly Message-ID: <199603050134.SAA07284@phaeton.artisoft.com> In-Reply-To: <199603050101.RAA19104@Root.COM> from "David Greenman" at Mar 4, 96 05:01:03 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> John and I have discussed this before. Basically, use vadvise(sequential) > to inform the kernel that operations are primarily sequential, and then use > some sort of per-vnode working set quota to throttle the memory consumption. > ...but right now, we've got lot's of serious bugs to fix so projects like > this only get worked on when we're looking for a break (e.g. low priority). For what it's worth, BTW, an madvise type approach will fail to fix the problem if I'm running the SVR4/UnixWare developement environment under an ABI. The same is pretty much true of any commercial product, and commercial products for Linux are in the same boat. Short of that, I think we can determine advise for random I/O in terms of pageable images that are mapped executable, which should adequately handle the shared library and executable image problems, as well as swap store (since we control our own swap, us being the kernel and all 8-)). The default behaviour ought to be to quota-restrict the working set for a given vnode. It's possible to do the same thing on a per process basis, but that's a lot of work (it means indirect referencing ad summing the working set for shared files, which isn't really realistic). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603050134.SAA07284>