Date: Mon, 5 Oct 2020 11:27:33 -0400 (EDT) From: Brian Feldman <green@unixhelp.org> To: Terry Lambert <tlambert@primenet.com> Cc: Andrzej Bialecki <abial@nask.pl>, freebsd-current@FreeBSD.ORG Subject: Re: VM question (QCAM question) Message-ID: <Pine.BSF.4.02.12010051123470.759-100000@zone.syracuse.net> In-Reply-To: <199809030207.TAA05776@usr07.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Tiny change of subject here, but this is brought up now: the QuickCam driver was dropped out of -CURRENT do to "lack of interest"... well why? Many other things only have niche users, but are still here (things being drivers). I've already gotten the qcam driver to work perfectly on a 3.0 system, so I could easily post all the code to remerge in. Failing that-as a sidenote- if you redefine noselect to seltrue (symbols) in qcam_mod.o from a 2.2.* box should allow you to use that module on a -CURRENT box easily. Butwhy make it this hard, why not bring back the QuickCam code in -CURRENT? cheers, Brian Feldman P.S.: Yes, this means I am willing to maintain the code and keep it updated and working. 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. > > > > (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 > 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.02.12010051123470.759-100000>