Messages in this thread | | | Subject | Re: why swap at all? | From | FabF <> | Date | Tue, 01 Jun 2004 23:15:36 +0200 |
| |
On Tue, 2004-06-01 at 22:22, Valdis.Kletnieks@vt.edu wrote: > On Tue, 01 Jun 2004 22:14:26 +0200, FabF said: > > > Boring....You can't have X root layer swapped to disk as it's often used > > ! Some quick lsof | grep "libX" gives all frontal applications 'swapping > > sensible' .fuser can do 'user resource reverse'.Kernel _can_ 'appl. > > resource reverse' as well. > > The point you're missing is that if you use a rule such as "everything using > libX* isn't swappable", then the X *server* is suddenly the prime candidate for > swapping out (as it's quite likely the biggest user of memory not using libX*). > (Anybody who ever had the OOM killer whomp their X server to free up space > fast when the *real* problem was a cluster of 6 or 8 "large but still smaller > than the X server" processes knows exactly what I mean... ;) > > > PS: I'm not talking about inactive desktop box.Such box has to be rl 3 > > and is not meant to be user (geek) relevant :) > > So you're saying that I should have kicked my laptop down to runlevel 3 just > because I went across the hall to the machine room to help get a few servers > into racks? Or every time I go into a meeting, or get stuck on a longish phone > call? > > Also, be *very* careful equating "user" with "geek" - at least some of us are > trying to produce systems that suit the needs of non-geek users.... > As I said, I think this thread is "becoming offtopic" but what can be interesting is the swapping problem fragmentation :
1.Global inactivity (what you're talking about) 2.Application isolation (what we're talking about).
Geek or not, someone backgrounding an application doesn't want it to down the box for X seconds some minutes later when it comes back and such things arrive many times a day.Maybe you've got an idea about a better rule(s) then ? (I mean for the 2 cases)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |