Date: Wed, 28 Jul 1999 23:39:32 -0500 (CDT) From: Kevin Day <toasty@dragondata.com> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: toasty@dragondata.com (Kevin Day), crandall@matchlogic.com (Charles Randall), hackers@FreeBSD.ORG Subject: Re: Replace/rewrite reverse.c for tail(1) Message-ID: <199907290439.XAA69977@celery.dragondata.com> In-Reply-To: <199907290416.VAA66114@apollo.backplane.com> from Matthew Dillon at "Jul 28, 1999 09:16:18 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > :Because of licensing restrictions in our product, we are unable to ship with > :any GNU/GPL'ed tools, so I'm forced to fix 'tail' rather than use tac. (I > :saw tac, and agree that it is faster for this specific use) > : > :Any VM people wanna pipe up and make a suggestion so that I may make up a > :patch? > : > :Kevin > > I don't think madvise()ing it MADV_DONTNEED will work right now. The > madvise() calls only work with OBJT_DEFAULT and OBJT_SWAP objects -- i.e. > swap-backed memory. They will not do anything to pages owned by > file mmaps. > > We could fix vm/vm_object.c/vm_object_madvise() to handle > MADV_DONTNEED for other objects. It would not be too difficult to > do, actually, since we would be doing nothing more then moving the > (must be clean) page to VM cache to get it to be reused more quickly. > This is a fix I could make to CURRENT without too much trouble. > > -Matt > Wow, that's interesting. While I never looked at the code, I *thought* I was able to measure a speed boost in a certain large embedded application I'm working on, with adding some madvise()'s in to mmap'ed files. (Streaming video madvise'ed with MADV_SEQUENTIAL seemed to be slightly faster, but it may have been insignificant) This is a problem I've run into a few times before, actually. One-time use data that will shove the entire system out of ram, and no convenient way to tell the kernel that it shouldn't bother holding on to it. I believe dg ran into this too, and had some fix he was using on ftp.cdrom.com. In my application, when I play a movie, it'd be nice to be able to specify a priority. "Try to keep this, even if it means possibly swapping" (current behavior) or "Don't swap out anything for this object, it's far too large to bother with trying to hold on to it and/or it will only be used once." Granted 'large' is one of those fuzzy terms, but when you do know that the 900M file you're reading is being done sequentially from start to finish, swapping things out to try to keep more of it in swap is probably bad. :) Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907290439.XAA69977>