Re: Moving /tmp to tmpfs makes it useless
Ben Hutchings <email@example.com> 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
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:
Hui, lets hope that works better.