-----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-----
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
