Date: Thu, 3 Sep 1998 02:07:19 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: abial@nask.pl (Andrzej Bialecki) Cc: freebsd-current@FreeBSD.ORG Subject: Re: VM question Message-ID: <199809030207.TAA05776@usr07.primenet.com> In-Reply-To: <Pine.BSF.4.02A.9809022201100.22481-100000@korin.warman.org.pl> from "Andrzej Bialecki" at Sep 2, 98 10:32:41 pm
next in thread | previous in thread | raw e-mail | index | archive | help
[ ... 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. > (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 in the MFS that is in the file is actually *not* the page paged from the MFS. In other words, the pages are doubled. This is only bad for clean pages; for dirty pages, it's absolutely necessary to not corrupt the binaries in the MFS. This could be handled by defining an MFS to be an FS on a VM "device", and then modifying (significantly) the MFS getpage/putpages routines to return direct mappings. I estimate that you will save, on average, on text page by doing this. > * 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? 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. These are both asking a lot. 8-(. 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?199809030207.TAA05776>