From owner-freebsd-questions Mon Oct 22 19:28:41 2001 Delivered-To: freebsd-questions@freebsd.org Received: from smtp.ufl.edu (sp28en1.nerdc.ufl.edu [128.227.74.28]) by hub.freebsd.org (Postfix) with ESMTP id 7983937B405 for ; Mon, 22 Oct 2001 19:28:35 -0700 (PDT) Received: from garbonzo.hos.ufl.edu (neti.eng.ufl.edu [128.227.235.15]) by smtp.ufl.edu (8.12.1/8.12.1/2.2.3) with ESMTP id f9N2SRiq094194; Mon, 22 Oct 2001 22:28:32 -0400 Message-ID: <3BD4D5CA.82D41DB5@garbonzo.hos.ufl.edu> Date: Mon, 22 Oct 2001 22:28:26 -0400 From: Bob Johnson X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Marco Radzinschi Cc: Bob Johnson , questions@freebsd.org Subject: Re: Q: Inactive vs. free memory? References: <20011022182357.X3056-100000@mail.radzinschi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Marco Radzinschi wrote: > > On Mon, 22 Oct 2001, Bob Johnson wrote: > > [snip!] > > > The relatively short answer is that "Inactive" memory is dirty > > memory that needs to be written to swap before it can be reallocated. > > "Cache" is memory that can be reallocated immediately, either because > > it has already been written to swap, or for some reason it can be > > reused without doing so (I suppose an example of this would be > > executable code that will be re-read from the original file if it > > is needed again). > > > > Memory gets into the "Inactive" or "Cache" queue by not being accessed > > for a while. Something is still claiming it, but since it hasn't been > > accessed recently, it is considered a good candidate for re-use > > when something else needs some physical memory. If the process that > > owns the memory accesses it, it will be moved back to "Active" without > > any swapping being necessary. > > I thought that it was unlikely that my system had 174 MB of memory > that would need to be swapped out before being reclaimed, since I am sure > it did not actually NEED that much memory. That is, there is no way it > was working with that large a data set. > > I wanted to see what would happen if it was needed, so I started enough > processes to eat up 200+ MB of RAM, and what I observed was that the > system first used the cache memory, as you said it would. Then the inactive > memory started dropping fast, and the active memory count started going > up. It DID NOT, however, start paging until the inactive memory was down > to a few megabytes. From this I conclude that inactive memory need not > necessarily be paged out in order to be reclaimed. That's correct. As I understand it, inactive memory is not checked for whether it needs to be written to swap until it is needed, for better efficiency in the common case where it is never needed. Keep in mind that inactive memory will often become active again when the process it belongs to wakes up and starts doing something, and even if it is reclaimed, it often doesn't need to be written to swap (read-only memory, for example). Presumably, the VM system finds all of the inactive memory that doesn't need to be written to swap and reclaims it before it starts writing to swap. Writing a page out to swap is EXTREMELY expensive in terms of processor cycles, so it is worth a fair amount of effort to avoid swapping until it is absolutely necessary. There are a lot of things that can create inactive memory that doesn't need to be swapped to be reclaimed. Anything owned by a process will become inactive if it isn't used for a while. If it is read-only, it can be thrown away, and re-loaded from the original file. In some circumstances, at least, writable memory that hasn't actually been written to will also end up as inactive memory, and can be discarded when it needs to be reclaimed. > > In my particular case, I believe Samba eats up RAM when I transfer several > gigabytes over the network, which ends up as inactive. It still seems odd > to me that it does not end up as cache memory, but it seems to work just > as well. If my understanding is correct, it ends up as inactive because the VM system doesn't bother to check whether it needs to be swapped until it needs to reclaim it. It will be converted to cache only when it is needed. Again, keep in mind that inactive memory is still owned by a process: it simply hasn't been accessed for "a while". The owning process could start using it at any time, so there is no real advantage to reclaiming it until it is actually needed in the general case. If Samba is actually allocating buffers and then freeing them, it would make sense for that memory to move straight to cache since Samba isn't going to be using it any more, so either Samba is not quite doing anything that simple, or the VM system leaves the pages allocated to Samba as long as possible on the assumption that if it recently allocated a large amount of memory, it is likely to do so again. That gets into details of the VM system that are way beyond what I know about it, but I do know that when you dig into it, it gets very complicated. If, for example, Samba is doing a lot of forking to handle your transfers, the forked processes will share some memory pages and will have their own copies of others, so what really happens as things age can be hard to explain with my superficial level of knowledge. > > Thanks for the input, Thanks for the question. It prompted me to think through the VM system more thoroughly than I had in the past. > > Marco Radzinschi > > E-Mail: marco@radzinschi.com > AOL IM: CrackedBoy > > Running FreeBSD 4.4-RELEASE i386 > 6:23PM up 1 day, 4:32, 1 user, load averages: 1.00, 1.00, 1.00 - Bob To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message