From owner-freebsd-questions Fri May 10 13: 8: 2 2002 Delivered-To: freebsd-questions@freebsd.org Received: from gatekeeper.orem.verio.net (gatekeeper.orem.verio.net [192.41.0.8]) by hub.freebsd.org (Postfix) with ESMTP id 0AED937B403 for ; Fri, 10 May 2002 13:07:56 -0700 (PDT) Received: from mx.dmz.orem.verio.net (mx.dmz.orem.verio.net [10.1.1.10]) by gatekeeper.orem.verio.net (Postfix) with ESMTP id 958543BF409 for ; Fri, 10 May 2002 14:07:55 -0600 (MDT) Received: from vespa.dmz.orem.verio.net (vespa.dmz.orem.verio.net [10.1.1.59]) by mx.dmz.orem.verio.net (8.11.6/8.11.6) with ESMTP id g4AK7sd79895; Fri, 10 May 2002 14:07:54 -0600 (MDT) Date: Fri, 10 May 2002 14:24:21 -0600 (MDT) From: Fred Clift X-X-Sender: To: Bill Moran Cc: Fred Clift , Subject: Re: pinning a process in real mem (ie unswappable) In-Reply-To: <3CDC26EB.2090605@potentialtech.com> Message-ID: <20020510141514.S49351-100000@vespa.dmz.orem.verio.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thanks for taking the time to read my blathering, and thanks for the ideas... On Fri, 10 May 2002, Bill Moran wrote: > You may want to research this a bit further, because I'm not 100% sure, > but I think the sticky bit _used_ to do this. It doesn't do it in > modern versions of FreeBSD. In general, I don't think there's any > way to do what you ask. Well, from what I understand, it used to leave your process pages in swap so that if you re-invoked the command soon that it could be read out of swap - doing this to commonly used programs (ie cc if you were doing a big multi-module compile) would help... Of course, this is no longer the case... > > Except, why not just buy enough memory that the machine never has > to swap? With current prices at cents/meg, it seems a pretty > reasonable thing to do. Well, afaik, freebsd maxes out at 4 gig of ram or thereabouts, without mucho monkeying. The process itself isn't that big, but gets swapped out due to infrequent use/other memory hogs in the system that I cant control) and the time it takes to get it swapped back in makes a noticiable difference in this need-to-be-low-latency process. In actuality, I can add more ram and solve my immedaite problem, but it will come back in a month or 3 when more ram is used by more of the same... I haven't recieved any other answers to my question, but I just found the 'mlock()' call that I might be able to use. I was hoping for a shell-utility but I could alter the program to mlock much of itself. Again, thanks for your suggestions :) Fred -- Fred Clift - fclift@verio.net -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message