--- Derek Glidden <dglidden@illusionary.com> wrote:
> Norbert Cartagena wrote:
Derrick, thank you also very much for your response.
--Justin Keyes
> > Actually what you're seeing is pretty normal. Here's a
> > short explanation about what's very possibly going on
> > (I don't know MUCH about this, but I'm sure someone
> > can expand upon this). The way the kernel works when
>
> Briefly:
>
> Linux (and other modern UNIX-like systems) utilize a unified
> memory/file
> cache VM system. Whenever you read anything from or write anything
> to a
> block device (i.e. hard drive, floppy drive, cdrom drive) those
> blocks
> are also cached in memory in case you need to use them again any time
> soon.
>
> Also, as gNorb pointed out, when programs get loaded and executed,
> the
> various libraries and system "things" that get loaded into memory
> also
> sit around even after they've stopped being used.
>
> Like Norb outlined, when stuff like that is in memory, that amount of
> memory shows up as "used." That memory stays allocated until memory
> pressure forces the VM to start reclaiming blocks. Typically the
> first
> thing to go are buffer cache blocks - i.e. stuff cached from block
> devices. The thinking is that you can always re-read them off disk
> if
> necessary. Only when you've reduced the amount of buffer cache to a
> threshhold minimum value (settable in /proc/sys someplace) will the
> VM
> start to swap program pages out to disk, thereby freeing up more
> physical RAM.
>
> What's kind of interesting about this approach is that the same
> memory
> pages are shared between the buffer cache and program memory. In the
> olden DOS and Windows 3.x days, stuff like "smartdrive" used to be
> required to pre-allocate a certain amount of memory exclusively for
> caching disk reads/writes. The idea of a unified memory space is
> fairly
> new, and I'm not entirely convinced that even "modern" versions of
> Windows utilize this kind of VM system since I've seen Windows boxes
> with 4GB of RAM thrash hard drives under even moderate reads/writes
> as
> long as you keep reading/writing enough different data.
>
> So how much memory your kernel reports as "used" is entirely up to
> how
> much stuff you've read/written to disk lately. It's entirely
> possible
> that even with 2GB of RAM, you can actually show all 2GB of RAM being
> "used" even when you have no programs in memory because all of that
> memory has been allocated for buffer cache or program cache, even
> though
> it's not in use anymore.
>
> If you want to see how much memory programs are actually taking, use
> the
> command:
>
> ps axv
>
> and that'll show you various memory-related statistics about what's
> currently running.
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> #!/usr/bin/perl -w
> $_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map
> {$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;
> $t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)
> [$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join
> "",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
> unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d
> >>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*
> 8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}
> print+x"C*",@a}';s/x/pack+/g;eval
>
> usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \
> | extract_mpeg2 | mpeg2dec -
>
> http://www.cs.cmu.edu/~dst/DeCSS/Gallery/
> http://www.eff.org/ http://www.anti-dmca.org/
> http://www.sciencemag.org/cgi/content/full/293/5537/2028
=====
/"\ ........................................................
\ / ASCII Ribbon Campaign | Justin Keyes
X - NO HTML/RTF in e-mail | m9u35@yahoo.com
/ \ - NO Word docs in e-mail | . .
\ /
,~~~~~~~~ O
(__________)
__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 17:00:50 EDT