Joachim Schrod said the following on 05/07/2013 04:22 AM:
I beg to differ.
Good, but what are you differing with? My opening line, which people keep deleting was Or NOT as the case may be
My current workstation (a Dell Optiplex) has 8 GB; when I bought it two years ago that seemed to be sufficient.
Sufficient for what? Did you have a use-case in mind or was it just "That was what available for what I was willing to spend"? Its that "seemed" that bothers me. How did you measure acceptability?
Start two or three VM instances, two Eclipses, have Chrome and Firefox running, and some associated programs, and you want to have the rest of those 8 GB available for filesystem buffering -- and not just for /tmp.
We keep saying "YMMV". My experience is that there are many cases where context switching kills performance and that can be tuned. I've also seen a lower speed, multi-core system do better in the kind of workstation, interactive setting than a single core system with the same memory, even before tuning. There's also "what's active?" I don't do code development, but I d a lot of writing and presentation work. Browser and file system and PDF readers, but I can shit down many other things. If I'm not going to use it for a while then its taking up memory anyway! The reality is that you're focusing on one thing at a time. If you system is fast enough then it *could* page everything else out and all of the one thing that matters in. In reality though you should tune your paging system as to how aggressive it is about paging out unused parts so that the working set of the apps you are switching between are resident. So long as they are resident little else matters. What are they? Well that depends, as I keep saying on you use case, and whether tmpfs will help depends on the case - like I said above, the use case.
Add the tendency of programs to place very large files (several GBs) in /tmp, and then you know why I think it's preferable to have /tmp on disk.
Ah, not always. Sometimes you want the content of that file back fast; perhaps its a sort of lookup table. It all depends on the use case.
Btw, I want to use swapping only in dire circumstances and not on a regular base; it affects all running applications and not just those that have content on /tmp.
"Dire"? I'm using the term paging here, not swapping. "Swapping" implies a completeness, like in the PDP-11 days where the whole program was swapped in and out in its completeness. Hopefully your VM system isn't doing that. Its a DEMAND PAGED virtual memory system. What gets paged out is paged out because (a) it hasn't been used in a long time and (b) something else need the memory. If you system is swapping out whole programs in their completeness so that something else can run then yes your are in a dire situation. Something is seriously wrong and the issue of disk vs tmpfs isn't the cause and isn't a factor. Paging, on the other hand, is the system's response to what you are doing requiring more memory of the working set than is physically available. Its perfectly normal. A well configured system will be reluctant to page. But when it does it does so because there are no alternatives. Yes you can tune the virtual memory in various ways. Yes you'll need to learn in order not to make a mess of it, but that applies to everything in life from relations ships with your partner, though driving a car to programming. Methinks you're trying to assert some absolutes; you shouldn't. There's a lot of YMMV with Linux. Its why so many things, the Virtual memory system being just one of them, is tunable.
That's also the reason why I think that any file left over in /tmp by an application after its termination is a bug in that application. Applications should clean up after them and should leave temporary files only after crashing. And then they *should* leave them so that one can analyze the situation better...
I'd emphasise all the SHOULD in that paragraph and insert a few more. But the reality is that we have to live with what we have. Some developers are reluctant to modify their code. (Others are dead.) -- "In the confrontation between the stream and the rock, the stream always wins ? not through strength but by perseverance." -- H. Jackson Brown. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org