> If you're using ramfs/tmpfs, it doesn't - there is no extra caching. > It looks like cache, but that's because the ramfs uses the cache to > hold its data. > > If you're using "RAM block device" (drivers/block/brd.c), it does, but > you would probably only be using that with a compressed filesystem, in > which case the caching is useful. > > Unfortunately for your wish, the page cache is too closely related to > the way I/O works to eliminate it. Realistically all you could do > would be to discard it shortly after using it for I/O. That is > possible by tweaking the heuristics in mm/. You can use O_DIRECT to > bypass page cache, but there are too many restrictions to use that for > general application I/O, and it's not clear if it's reliable on all > architectures anyway due to DMA coherence issues.
Well if I look at the size of the kernel, the size of the initramfs when uncompressed, and the amount of ram used by applications, I seem to very quickly be missing the amount equal to the size of the initramfs (and amazingly the cache value looks suspiciously like it). The cache causes horrible fragmentation of memory and when you only have 8MB, and running from a ramdisk already using execute in place, you really really don't have any need for caching at all, especially when it fragments memory so badly. Of course I may have misunderstood where the ram is being used. I haven't figured out how to tell what memory is used for what yet. On regular MMU based linux systems it always seems pretty obvious where the ram is and what is using it. Not so on the NOMMU system so far. -- Len Sorensen _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
