"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])

Reply via email to