Date: Fri, 17 May 1996 10:43:55 -0500 (CDT) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: toor@dyson.iquest.net (John S. Dyson) Cc: syssgm@devetir.qld.gov.au, freebsd-hackers@freebsd.org Subject: Re: joe's questions on vm/mincore/etc. Message-ID: <199605171543.KAA15402@brasil.moneng.mei.com> In-Reply-To: <199605171450.JAA00769@dyson.iquest.net> from "John S. Dyson" at May 17, 96 09:50:16 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > >(I was looking at this in part because it works under at least one other > > >major OS, SunOS/Solaris, and I run news servers under both environments). > > > > At first glance his suggestion looks hideously non-portable, but there is > > nothing stopping you from writing a system call that does the mapping, and > > a FreeBSD/i386 specific library routine (called mincore) which gropes the > > mapped ptes and gives you your answer. Second and subsequent mincore calls > > would not call the kernel. Thus you keep the published interface and > > published behaviour, yet have nasty (hopefully fast) code behind the scenes. > > > > You could implement that SystemV ipc stuff with these sorts of tricks too, > > and eject it from the kernel. Anyone for a kernel purity purge? :-) > Problem is that there are (sometimes) alot of pages in an object that are > not mapped into the process, but are in memory. The pte's are only part > of the picture. If you use the pte mechanism, you'll get information > about pages that are in memory, and won't have to be faulted into the > process. The scenario, I assume, where this would happen is where somebody else accesses the page? I would _guess_ that this would not be a significant issue (or an issue at all) for a scenario where a single process was involved. This is the case I am dealing with :-) . Given past experience with systems engineering, I will forward this counterproposal, without having ANY idea how easy it might be to implement: A general purpose function to reveal information about VM issues. I would like to be able to determine: o Page mapped by pte and incore o Page mapped by pte and not incore o Page not resolved by pte (yet) (those three should be easy, as far as I can tell) o Page available incore o Page not available incore (harder) o Number of references to a page (maybe split into non-COW and COW sharings, etc)? to help determine efficiencies of shlibs, etc. o Other relevant detailed information. (*****!!!!!!!) I would not mind taking a syscall hit for this sort of info, maybe even if I had to retrieve information about pages one at a time :-) This sort of information is noticeably lacking in most OS's, and systems engineers like me are constantly swearing because we can't systematically determine the benefits of sharing libraries and things like that. We have to look at the bigger picture and make a "judgement call". I don't mind adding a code to an application to iterate through all its pages and gather statistics... but I hate that the information needed for the statistics is not available. Maybe a facility to map the pte's, and a separate facility to get more detailed information about a particular pte, for those of us who might care (and don't care about a syscall hit to get that additional info)? Does this sound like a Project yet? ;-) You did say you wanted something to do this weekend ;-) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605171543.KAA15402>