From owner-freebsd-current@FreeBSD.ORG Sat Apr 19 14:05:02 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C2DE37B401 for ; Sat, 19 Apr 2003 14:05:02 -0700 (PDT) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1AB143FCB for ; Sat, 19 Apr 2003 14:05:01 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0234.cvx22-bradley.dialup.earthlink.net ([209.179.198.234] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 196zW7-0003iJ-00; Sat, 19 Apr 2003 14:05:00 -0700 Message-ID: <3EA1B915.D0B26399@mindspring.com> Date: Sat, 19 Apr 2003 14:01:09 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Lucky Green References: <000a01c306b5$9092c190$6601a8c0@VAIO650> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4d16f1a53ef877bfe78999c412d85376d666fa475841a1c7a350badd9bab72f9c350badd9bab72f9c cc: freebsd-current@FreeBSD.ORG Subject: Re: Broken memory management on system with no swap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2003 21:05:02 -0000 Lucky Green wrote: > Terry wrote: > > This is generally an attempt to get a swap mapping for > > backing store for the process. It could be that all your > > "inactive" memory has been spoken for. > > I had been under the impression that inactive pages contained data that > is no longer being used by a program, but is kept around in case the > data may be needed again in the future. Is it not the case that inactive > memory should be available to active processes if the processes require > more memory? It is LRU'ed. If all the cache contents have been more recently used than the contents of the dirty page that's potentially going to be swapped, then the cached contents are "more precious" than the page being swapped, even if no one is currently referencing them. In any case, I don't think this is what's happening, but without a stack traceback, it's hard to tell exactly which of the 3 cases is really happening. You really need to give us a stack traceback, so that we don't have to analyze all three code paths, and can concentrate on the one that is biting you. > > If you had provided a traceback, I would guess that this > > happened as a call from swap_pager_reserve(), as opposed to a > > call from > > swap_pager_strategy() or swap_pager_putpages(). This can > > only happen if you are using an md device; are you using an > > md device (ramdisk)? If so: cut it out, or make sure the > > MD_RESERVE bit is not set. > > "device md" is compiled into the kernel, but to my knowledge I am not > using any MD devices. Should I remove this entry from the kernel config > file? I don't know if the problem is coming from there. Can you give us a stack traceback? Compile your kernel with BREAK_TO_DEBUGGER and DDB, and then replace: printf("swap_pager_getswapspace: failed\n"); with: panic("swap_pager_getswapspace: failed\n"); in /usr/src/sys/vm/swap_pager.c in swp_pager_getswapspace() at about line 474. Then post a traceback so we can tell who called it. -- Terry