Ben Hutchings <b...@decadent.org.uk> writes: > On Fri, Jun 01, 2012 at 11:19:40PM +0200, Carlos Alberto Lopez Perez wrote: >> On 01/06/12 13:33, Goswin von Brederlow wrote: >> >> > I don't know the ultimate reason behind this ugly behaviour of Linux >> >> > when the swapping process is happening, but I know this is real and it >> >> > happens because I have experimented this situation myself more than a >> >> > couple of times. >> > It's a matter of that gets swapped and linux choosing the wrong thing to >> > swap (far too often). There is some "bug" in linux that when you have >> > lots and lots of IO at some point the swap heuristics tip over and start >> > swapping apps and usefull data to create more cache space for >> > IO. Doesn't matter that you already have 3GB for cache, it still swaps >> > out your mouse cursor and then things go real bad. >> >> This makes sense. Many times I have experimented this situation while >> copying a large file from a quick device (hdd) to a very slow device >> (cheap usb stick) >> >> IMHO The logical way of behaving in such situation is to slow-down the >> IO bandwidth of the processes that are filling the cache, by sending to >> sleep any process that requests more IO while the cache is full instead >> of trying to free RAM by swapping out things from the RAM to the swap. >> >> Do you know any way to avoid (or mitigate) this? Perhaps some sysctl >> variable?
There are 2 settings for that, one to limit the number of dirty pages before writing them starts and one to limit the number of dirty pages being written (being on-the-fly) at any one time. The defaults are iirc 30% and 10% but none of that seems to matter. A process writing to a slow devcie isn't put to sleep if the limits are exceeded so it keeps eating up memory with dirty pages. >> Can't Linux be configured to just block (sleep) any process that >> requests IO while the cache is full? >> >> Perhaps a good idea would be to limit the cache size on a per-PID basis >> and block (sleep) the pid while its cache is full. > > I don't think it makes any sense to have a hard per-process limit. > Also, it's not generally possible to account dirty pages to specific > processes exactly. But I think you will be pleased with this change > that was included in Linux 3.2: > > http://lwn.net/Articles/456904/ > > Ben. Hui, lets hope that works better. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bokydx4p.fsf@frosties.localnet