"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> Given the right allocation proportions, this may mean that in the end the
> kernel has no way to handle a shortage gracefully by causing fork() or
> allocations to fail.
Sure it does. All you need is a conservative allocation policy: fork()
fails if it cannot reserve enough swap space to guarantee that the new
process could write over its entire address space. Copy-on-write is
an optimization that reduces physical RAM usage, not virtual address
space or swap-space requirements.
Given that swap space is cheap, and that killing random processes is
obviously bad, it's not apparent to me why people think this is not
a good approach --- at least for high-reliability servers. And Linux
would definitely like to think of itself as a server-grade OS.
> After that, where do you go? Try to find a reasonable process to shoot
> in the head. From what I heard, although I haven't kept current, a lot
> of work went into selecting a "reasonable" process, so there will be some
> determinism.
Considering the frequency with which we hear of database backends
getting shot in the head, I'd say those heuristics need lots of work
yet. I'll take a non-heuristic solution for any system I have to
administer, thanks.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
