I'm tempted to test out Andrea's vm to see if it locks just as easily.
> | Swapping out whole processes can help this, but it will merely
> | move the point where you get stuck. A load control system that
> | kills processes when response is too slow is possible, but
> | the problem here is that you can't get people to agree
> | on how bad is too bad. It is sometimes ok to leave the machine
> | alone crunching a big problem over the weekend. And sometimes
> | you _need_ response much faster.
> |
> | And what app to kill in such a situation?
> | You had a single memory pig, but it aint necessarily so.
>
> I think the problem is not killing the wrong thing, but not killing
> anything... We can argue any old factors for selection, but I would
> first argue that the real problem is that nothing was killed because the
> problem was not noticed.
>
> One possible way to recognize the problem is to identify the ratio of
> page faults to time slice used and assume there is trouble in River City
> if that gets high and stays high. I leave it to the VM gurus to define
> "high," but processes which continually block for page fault as opposed
> to i/o of some kind are an indication of problems, and likely to be a
> factor in deciding what to kill.
>
> I think it gives a fair indication of getting things done or not, and I
> have said before I like per-process page fault rates as a datam to be
> included in VM decisions.
-
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/