Date: Thu, 3 Sep 1998 22:29:35 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: abial@nask.pl (Andrzej Bialecki) Cc: tlambert@primenet.com, freebsd-current@FreeBSD.ORG Subject: Re: VM question Message-ID: <199809032229.PAA02145@usr09.primenet.com> In-Reply-To: <Pine.BSF.4.02A.9809031012020.12804-100000@korin.warman.org.pl> from "Andrzej Bialecki" at Sep 3, 98 10:35:57 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > It makes no sense to do this. These pages aren't bothering anyone, > > and will go away when it is necessary for them to do so. > > I think from my point of view it _is_ necessary to free as much as > possible (including .text and .data pages of other processes) in order to > be able to start the new process; And this is precisely what *will* happen. When unused cached pages compete with new pages, the old pages lose, and are replaced. What you are suggesting is throwing away cached pages that may be about to be reused because you think that maybe later you will load something else. The tiny increase in speed in mapping new pages vs. unmapping old pages and then mapping new pages, is not worth the cost in cache locality losses, unless you are regenerating your executables each time. Even then, as the CS department of the University of Utah was able to dramatically demonstrate, keeping around pre-relocated chunks of code for mapping into process address spaces is still a win. The only place I can think of where this would not be a win is a Symbolic's LISP machine, a UCSD P-code machine, or a JAVA chip. At that point, though, it's not an issue for a FreeBSD VM any more, since you wouldn't be running FreeBSD. > and to do the same to the newly started process when its turn to > run ends. Of course this will result in excessive paging, but these > will be only page-ins and discards, right? I am unconcerned about the page-in's, given the architecture you have described. I am more concerned about tearing down page tables and PTE's for VM objects that aren't taking up space, and which might otherwise be reused. Realize that by doing this, you will be engaging in L1 and L2 cache busting, and unless your I/O and memory bus speeds are the same as L2 cache access (minimally), then what you are doing is a pessimization. > What happens to clean pages in normal situation, i.e. with swap? Are they > just discarded when system is low on memory, or are they swapped together > with dirty pages? They are discarded. > All I want here (i.e. without swap) is to discard as > many (all?) clean pages as possible, because I can always (quickly) reload > them if they are referenced; as far as I understand this, this is not the > current behaviour, which is to keep as many pages as possible either > loaded or swapped out. Clean pages are not written to swap. See PHK's correction to an article I wrote where I had errnously reported that they were. In fact, clean pages *should* be written to swap, rather than discarded, both because the swap pager is faster than the vnode pager (and always will be) for reading pages in, so you might as well swap them if you can. Not that this matters, since you said you will be setting NO_SWAPPING (the same as not cinfiguring any swap space). > > I estimate that you will save, on average, on text page by doing this. > ^-- one > You mean, one page for each page of .text - this is not negligible gain... One page of text per file. > > > * to limit killing of random user processes - instead the VM should try > > > first to free as much pages as possible (and it should try better than it > > > is doing now :-) > > > > There are two problems glossed together here: > > > > 1) What if you really *are* out of memory? > > Let me rephrase this: what if my memory is filled with dirty pages? Then > resort to killing. BUT: what if my memory is filled with some dirty pages > and some clean pages? IMHO, I should free the clean pages immediately > (except one-two which are being referenced just now :-) The clean pages will be displaced by dirty pages, as needed. That's how it works. > Yes, if we're talking about dirty pages. But I'd bet in current schema > there are many clean pages kept in-core in order to avoid excessive > paging. I need to change this to bare minimum, because I don't consider > page-ins from MFS to be expensive. But by doing this, you won't get more usable memory, so what's the point? Better to rewrite MFS, in the way I have suggested... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809032229.PAA02145>