[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Memory usage: buffer and cache



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all!

|> I'm not sure but what do you mean when you say "Linux doesn't see
|> the CPU cache."

I think he meant that the CPU cache isn't directly accessible for linux
as for any other OS. It is inside the chip and there it stores recently
accessed memory pages (and their addresses) to speed up following
accessed to that memory page (indeed since cpu cache runs at cpu clock
speed and is sram it is much much more faster than fetching a memory
page from main memory or even from a disk).

|> On my Intel Centrino laptop the /proc/cpuinfo file does point out
|> that the processor has a 2mb capacity of L2 Cache.

Right, it also will have some layer 1 cache. Both are on chip, if a
requested memory page isn't in layer 1 cache at next the cpu (not a OS)
will look into layer 2 cache. 2MB doesn't seem very large in view of
sizes of main memory - but often programms have some variables (data)
that is read/written quite often (a counter in a loop for a simple
example) and these variables could fit into one memory page. So if this
page is in the cache, while running the cpu doesn't need to fetch pages
from memory too often.

|> May be I'm wrong and have misunderstood the whole thread.

| Linux sees that it's *there*, but doesn't/can't do anything with it.

Right, Linux and any other OS can't do something with these hardware
caches directly, right. Neither they can use your hard drives cache
directly (and there are some more).

But in the beginning of this thread I read about

| Buffers:        138752 kB
| Cached:         326116 kB

Look into kernel documentation, prod-filesystem:

Buffers: Relatively temporary storage for raw disk blocks
~         shouldn't get tremendously large (20MB or so)
~ Cached: in-memory cache for files read from the disk (the
~         pagecache).  Doesn't include SwapCached

Buffers here mean, this is a memory space, where to put the raw data
blocks (muliples of 512 bytes) comming from your harddrive. After that a
filesystem module must interpret what this data means and do something
useful with it. If some data is modified a special flag (dirty_flag) is
set to that buffer - which means that these data is not the same a the
actually disk data, so a write is needed. If there are enough dirty
pages, these are written back to disk.

Cached instead is a cache for files read from disk. You notice it's
funtion if you access a file. First time you access it, it takes some
time since it is loaded. If you close it and then reopen it, this is
much faster:

teefix:~# time cp linux-2.6.8.1.tar /dev/null
real    0m10.456s
user    0m0.049s
sys     0m1.408s
teefix:~# time cp linux-2.6.8.1.tar /dev/null
real    0m0.975s
user    0m0.034s
sys     0m0.911s

After doing much disk access:

teefix:~# time cp linux-2.6.8.1.tar /dev/null
real    0m10.474s
user    0m0.036s
sys     0m1.433s
teefix:~# time cp linux-2.6.8.1.tar /dev/null
real    0m1.007s
user    0m0.036s
sys     0m0.936s

Hope I'm not too wrong in my explanation - if drop me a mail :-)

Cheers,
Jan




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBe2vOvvmCkIIgH8QRAiipAKC7W+17Pc0hr3bhk6Wl/k1fm83qjgCdGycu
H29/xJ44cNuvZtaib625tc0=
=io+x
-----END PGP SIGNATURE-----



Reply to: