![]() | |||||||||||||
Messages in this thread |
On Tue, 3 Mar 1998, Michael L. Galbraith wrote: > > To 'recover from' or 'handle' your attack (180+ mb working > > set on an 80 mb machine) is going to need 'real' swapping, > > ie. the temporary suspension of processes to reduce VM load. > > I've run much larger working sets on this machine without either > losing control or having the tasks killed. I've run simulations > which ate 400+ Mb. The realtime aspect was a joke, but it worked. When allocation is done piece-by-piece, and there's only one big process which is faulting all the time, all known Linux kernels can handle it (more or less). > > This patch is only an improvement for normal use. Anyways, > > thrashing can't be combatted by paging algorithms, no matter > > how good. > > OK.. thought you wanted it pounded upon. You were right about that. I wanted to be sure that my patch was at least as solid as the old code before it gets merged into the kernel. Judging from the reports I got, it is. In fact, most people have reported a big improvement, and some people have pounded and ground it to a crawl (without being able to make it crash). > It was running fine with all tasks being scheduled smoothly until > something triggered a mega-thrash. Once you start thrashing, only real swapping is an option to save performance (somewhat). > > I'll be working on the swapping daemon as soon as I've got > > the current patch sorted out... > > Turned out the kswapd messages weren't related to the thrashing. > I would have seen it if I hadn't jumped straight into X. Ahh, yes. X allocates a _lot_ of memory at once, and then the damn thing _uses_ it at once... This is guaranteed to make kswapd a bit nervous, both with or without my patch. Rik. +-----------------------------+------------------------------+ | For Linux mm-patches, go to | "I'm busy managing memory.." | | my homepage (via LinuxHQ). | H.H.vanRiel@fys.ruu.nl | | ...submissions welcome... | http://www.fys.ruu.nl/~riel/ | +-----------------------------+------------------------------+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu | ||||||||||||
| Last update: 2005-03-22 12:41 [from the cache] ©2003-2008 | |||||||||||||