Date: Thu, 3 Sep 1998 10:35:57 +0200 (CEST) From: Andrzej Bialecki <abial@nask.pl> To: Terry Lambert <tlambert@primenet.com> Cc: freebsd-current@FreeBSD.ORG Subject: Re: VM question Message-ID: <Pine.BSF.4.02A.9809031012020.12804-100000@korin.warman.org.pl> In-Reply-To: <199809030207.TAA05776@usr07.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 3 Sep 1998, Terry Lambert wrote:
> [ ... RAM and "fast swap" (RAM) ... ]
>
> > ...and here's what I'd like to achieve:
> >
> > * to free pages aggressively, so that only a very few pages (a fraction of
> > .text and .data, the stack and bss) are paged in, and then as soon as
> > possible freed - it's relatively cheap to do pagein when the media that
> > holds binaries is very fast,
>
> 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 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?
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? 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.
> > (As a side note: probably what I'd like to use is execution in place,
> > especially in case of MFS, but I remember someone telling me it's very
> > difficult to do...)
>
> Yes. It's rather hard. In the current implementation, the page
> 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...
> > * 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 :-)
>
> and
>
> 2) What if memory is fragmented?
>
> The second should only be a problem in the case where you need to
> allocate contiguous pages (for example, loading an LKM driver for
> a device that uses a contiguous physical memory segment to DMA
> into, like the QCAM driver).
>
>
> To solve the second, you would need to move around pages by discarding
> clean pages and copying dirty pages and modifying page table entries to
> point to the dirty page copies, in order to free up the originals. This
> has been discussed on this list before, as an alternative to grabbing
> large chunks of contiguous memory for devices at driver attach time.
>
>
> To solve the first, you will have to invent a mechanism, whereby an
> application can be asked to free up "dirty" pages, which contain cached
> data that can be regenerated or otherwise recovered without keeping
> them, and to free allocated memory, defrag it, and sbrk the freed
> memory back to the system.
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.
Andrzej Bialecki
-------------------- ++-------++ -------------------------------------
<abial@nask.pl> ||PicoBSD|| FreeBSD in your pocket? Go and see:
Research & Academic |+-------+| "Small & Embedded FreeBSD"
Network in Poland | |TT~~~| | http://www.freebsd.org/~picobsd/
-------------------- ~-+==---+-+ -------------------------------------
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?Pine.BSF.4.02A.9809031012020.12804-100000>