Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Oct 2001 22:28:26 -0400
From:      Bob Johnson <bob88@garbonzo.hos.ufl.edu>
To:        Marco Radzinschi <marco@radzinschi.com>
Cc:        Bob Johnson <bob89@garbonzo.hos.ufl.edu>, questions@freebsd.org
Subject:   Re: Q: Inactive vs. free memory?
Message-ID:  <3BD4D5CA.82D41DB5@garbonzo.hos.ufl.edu>
References:  <20011022182357.X3056-100000@mail.radzinschi.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BD4D5CA.82D41DB5>