On Tuesday 08 July 2003 16:20, Muli Ben-Yehuda wrote: > The memory will be freed by the caches whenever it will be necessary > elsewhere. I'm (very) lazily working on a kernel mechanism which will > allow you to say "don't let this cache grow over a given size", if you > really care (some database people do).
There's also the problem which've been bothering many desktop users -- I'd call it "the morning update-db blues". You're all familiar with this: coming to your workstation in the morning to find out those KDE and Mozilla you left overnight are horribly sluggish the first 10 seconds. Turns out that update-db, a program which makes sure the 'locate' utility has a fresh list of files to work with, scanned your entire hard drive ... and since the kernel is so generous, it pushed your idle KDE and Mozilla out of memory and cached the entire directory tree. The thinking people we are, we understand that cached data is of no use to us: we'd rather have our Mozilla respond immediately. But the kernel cannot know it ahead; it cannot know if the data it reads will only be used once. A solution could be, as I concluded after an IRC chat with mulix some time ago, that the kernel will favor cached executables and shared libraries (basically, everything with an executable file mode) over data files. Muli, is it possible or is the caching done on the block device level? ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
