Date: Fri, 16 Apr 1999 16:10:58 -0700 From: "David Schwartz" <davids@webmaster.com> To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: <chat@FreeBSD.ORG> Subject: RE: swap-related problems Message-ID: <000601be885e$63713720$021d85d1@whenever.youwant.to> In-Reply-To: <3717B87E.FF8B93AD@newsguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> In this particular case, it comes down to this: the problem is a > very complex one. A good solution, if one exists at all, is easily > the subject of a Ph.D. thesis. Effective solutions exist. Do not run > mission critical processes on machines were users cannot be trusted. > Put a cap on maximum resource usage on a per-user basis to prevent > mistakes they might make from bringing down the system. Give the > system enough resources for it's intended use. The problem is, none of these suggested solutions, either alone or in combination can solve the actual problem. Resource limits don't help because root's processes can run amuck too and there's no sensible thing to set them to. Not running important processes on multiuser machines is the NT philosophy, not the UNIX one. Giving a system more resources doesn't help -- giving it more RAM simply pospones the problem. Giving it more swap simply allows it to run slowly. Again, what's missing is feedback. > People have said all of the above, and then, rather than repeating > themselves, just gave up on this thread. Me, on the other hand, had > to spent two nights crawling the web after a few things, leaving me > a lot of free time between page downloads. I decided to spend this > time explaining why the problem is so complex, why the effective > solutions are effective, why the solutions proposed didn't solve > anything. Why doesn't the following solve the problem: 1) A separate swap space for 'critical' processes. 2) Critical processes are never overcommitted. Instead calls like fork, mmap, and malloc fail. 3) Critical processes aren't killed when the system needs to kill processes due to overcommittment. Now, I'm not saying this is the best solution to use. I'm simply saying that it's not overly complex and solves a real problem. A response is, "If you think it's so great, code it" is not only unhelpful, it's downright rude. > When you said you didn't want a simple solution, you wanted a good > one, there were few ways I could have answered. That there are no > resources it's obvious. It is a volunteer effort. The resources we > have are the volunteers, who do what *they* want or what *they* > need, not what other people want or need. Yes, that's one of the major disadvantages of an open source effort. It's really amazing that as much gets done as does get done. I guess different people have very different ideas about what's interesting. But certainly it doesn't help to say that things shouldn't be done. It's too easy to say, "That's a bad feature, that's why FreeBSD doesn't have it", but it's ultimately discouraging to those who might help and it's very defeatist. > I shouldn't have to tell > you that. I could leave it at that, but I thought that would sound > like saying it was a useless idea. Since it is not a useless idea, I > decided to express it so: send the patches. I wish I had the time. I really do. It bothers me that our software doesn't run well on FreeBSD. But I think that's more because of a lack of good kernel threads support than anything else. Actually, it's at least in part due to 'poll' not working correctly in FreeBSD's user-space threads implementation. DS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000601be885e$63713720$021d85d1>