Date: Fri, 17 May 1996 09:50:16 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: syssgm@devetir.qld.gov.au (Stephen McKay) Cc: freebsd-hackers@freebsd.org, syssgm@devetir.qld.gov.au Subject: Re: joe's questions on vm/mincore/etc. Message-ID: <199605171450.JAA00769@dyson.iquest.net> In-Reply-To: <199605170840.SAA07967@orion.devetir.qld.gov.au> from "Stephen McKay" at May 17, 96 06:40:18 pm
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. John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605171450.JAA00769>