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

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

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


On Mon, Jul 12, 2004 at 12:05:47PM +0200, Lars Marowsky-Bree wrote:
> On 2004-07-12T08:58:46,
>    Arjan van de Ven <arjanv@redhat.com> said:
> 
> > 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. 
> 
> Of course; appropriate safety measures - like not doing any syscall
> which could potentially block, or isolating them from the main task via
> double-buffering childs - need to be done. (heartbeat does this in
> fact.)

well the problem is that you cannot prevent a syscall from blocking really.
O_NONBLOCK only impacts the waiting for IO/socket buffer space to not do so
(in general), it doesn't impact the memory allocation strategies by
syscalls. And there's a whopping lot of that in the non-boring syscalls...
So while your heartbeat process won't block during getpid, it'll eventually
need to do real work too .... and I'm quite certain that will lead down to
GFP_KERNEL memory allocations.



[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]