On Tue, Sep 22, 2020 at 02:39:09PM +0200, Hans van Kranenburg wrote:
> How did you test it and how did you get a working process without the --?
By reading the man page, noticing there was no mention of "--" and then
trying `choom -n +5 sleep 5` and found that worked. When you sent this
message I
notfixed 961511 xen/4.14.0-1~exp1
thanks
Right... so in the end I made an off-by-one error while rebasing and
totally lost that commit. It's not actually in 4.14.0-1~exp1 now. That's
bad.
On 9/21/20 3:50 AM, Elliott Mitchell wrote:
> This is fun. Actually isn't too difficult to trigger, simply s
This is fun. Actually isn't too difficult to trigger, simply slowly
reduce the memory Xen allocates to Dom0 and eventually the oom-killer is
likely to trigger (having tried to shrink Dom0 as far as possible,
believe me, I know). I had been wondering which of the Xen daemons could
be safely restar
~Hans van Kranenburg writes ("[PATCH] d/xen-utils-common.xen.init: disable oom
killer for xenstored"):
> In case of oom killer terminating some process, we'd rather not see
> xenstored go. Xenstored has an in-memory database, and when starting the
> process again, it would be empty, which is very
tag -1 + pending
thanks
On 9/7/20 12:40 PM, Ian Jackson wrote:
> ~Hans van Kranenburg writes ("[PATCH] d/xen-utils-common.xen.init: disable
> oom killer for xenstored"):
>> In case of oom killer terminating some process, we'd rather not see
>> xenstored go. Xenstored has an in-memory database, an
In case of oom killer terminating some process, we'd rather not see
xenstored go. Xenstored has an in-memory database, and when starting the
process again, it would be empty, which is very inconvenient. Xenstored
should already score quite low and have a fairly low memory footprint,
but according t
6 matches
Mail list logo
