On 05/26/2012 09:20 AM, Nikolaus Rath wrote: > I believe tmpfs memory is swapped out preferentially, so your scenario > doesn't have to play out like that. However, paging being a complex > process, it's not impossible either.
<disclaimer>I haven't read the actual kernel code, just making assumption from what I generally know about swapping algorithms (eg: a long long time ago, I worked on something like that on Atari computers...).</disclaimer> What's going to go to the swap space are pages that have a lower rank. There are many ways to rank a page. But these pages are generally what hasn't been used often, and hasn't been used for a while. So let's say you start an app, and don't use at all some of its functions, it gets swapped out (if needed) until you start using it. This is where one can complain about the randomness of swap access: it's not really predictable from the user's point of view, while having a file written to /tmp is. If you access often files in your tmpfs, of course, they wont go to the swap, they will have a higher rank, and the kernel will decide to swap some pages that are less often accessed. And that's when it becomes very annoying, whatever is the swap algorithm: things go in and out of the swap space depending on how often you use them, when all your app cared was writing a (potentially) big file to disk. Here, we don't care if things are going faster (benches are useless), we care that it "feels" right, and we care our system is reactive to what the user asks for. Now, what happens if your /tmp gets full? Hum... generally, not much. The application fails, and if written correctly, displays an error message. If written badly, it simply crashes. In all cases, that's not a big deal. But if your swap gets full (or used really a lot), then it's a disaster. Your system becomes unresponsive to users commands, and sometimes even crashes (eg: the OOM killer starts acting funnily and kills random processes...). No way anyone wants this on his system. Even less a user with not a lot of experience, who just happen to choose the installer's default, and that wont understand what's happening. Thomas -- 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/4fc0716b.4040...@debian.org