On Tue, Jul 08, 2003 at 08:51:34PM +0300, Ilya Konstantinov wrote: > 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?
A simpler workaround: schedule a daily cron job of xrefresh after all the nightly jobs. -- Tzafrir Cohen +---------------------------+ http://www.technion.ac.il/~tzafrir/ |vim is a mutt's best friend| mailto:[EMAIL PROTECTED] +---------------------------+ ================================================================= 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]
