Re: [ANNOUNCE] Minneapolis Cluster Summit, July 29-30

[Arjan van de Ven <arjanv@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]


> 
> This however is not true; clusters have managed just fine running in
> user-space (realtime priority, mlocked into (pre-allocated) memory
> etc).

(ignoring the entire context and argument)

Running realtime and mlocked (prealloced) is most certainly not
sufficient for causes like this; any system call that internally
allocates memory (even if it's just for allocating the kernel side of
the filename you handle to open) can lead to this RT, mlocked process to
cause VM writeout elsewhere. 

While I can't say how this affects your argument, everyone should be
really careful with the "just mlock it" argument because it just doesn't
help the worst case in scenarios like this. (It most obviously helps the
average case so for soft-realtime use it's a good approach)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]