On Aug 26 2007 12:49, Fred Tyler wrote:Note that not all kernels have the 'drop_caches' control file. So there is not much you can do there. Well if it helps, you can accelerate the 'problem', by issuing, for example: (1) dd_rescue /dev/sda /dev/null -m $[4*1048576*1024] for reading 4 GB from disk straight and populating 'buffers'. (2) cat /some/big/big/big/file >/dev/null for reading X GB from disk and populating 'cache'. and then you'll see. Also note that a kernel leak will eventually lead to very low buffers/cached values (the ones to the far right) even when large amounts of data are read (using either dd_rescue/cat as mentioned above), because, of course, the leak clogs up memory. total used free shared buffers cached Mem: 775792 493724 282068 0 8 308416 -/+ buffers/cache: 185300 590492 Swap: 795136 60 795076 If you see an Out Of Memory notice in dmesg, you'll know there is a leak even if everything was shut down. Jan -- -
| Davide Libenzi | Re: [patch 7/8] fdmap v2 - implement sys_socket2 |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
| Greg Kroah-Hartman | [PATCH 005/196] Chinese: add translation of SubmittingDrivers |
| Mariusz Kozlowski | [KJ PATCHES] mostly kmalloc + memset conversion to k[cz]alloc |
git: | |
| KOSAKI Motohiro | [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" |
| Stefan Richter | Re: [GIT]: Networking |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
