| |||||||||||||
|
| |||||||||||||
2.6 swapping behavior2.6 swapping behaviorPosted May 6, 2004 19:31 UTC (Thu) by abatters (✭ supporter ✭, #6932)In reply to: 2.6 swapping behavior by guinan Parent article: 2.6 swapping behavior Well, there is mlock() et al., but that would be like trying to swat a fly with a sledgehammer. After closing a memory-hog program that was causing swapping, sometimes I just do "swapoff -a; swapon -a" to get the system responsive again.
(Log in to post comments)
mlock Posted May 8, 2004 17:44 UTC (Sat) by giraffedata (subscriber, #1954) [Link] Actually, mlock is conceptually exactly what's required here. We're talking about a case where the following assumption inherent in real memory allocation policy fails: the pages for which fast access will be most appreciated are those that were most recently used.Here, we have a user who is willing to let 32MB of memory sit idle overnight, even at the cost of slowing down other things, just so he can have immediate response every time he clicks his web browser. That's what mlock is about. I do a similar (but rather opposite) thing with a ramdisk. I copy various files that are used in tasks that I want to be responsive into a ramdisk. Ramdisk is just file cache that is locked in memory. That way, no matter how much memory pressure there has been since the last time I used these files, they're always right there when I click for them.
2.6 swapping behavior Posted May 13, 2004 16:50 UTC (Thu) by jonsmirl (guest, #7874) [Link] What about simply adding "swapoff -a; swapon -a" to the end of updatedb and prelink chron scripts?
|
|
||||||||||||