Messages in this thread | | | Date | Mon, 12 Jul 2004 12:11:07 +0200 | From | Arjan van de Ven <> | Subject | Re: [ANNOUNCE] Minneapolis Cluster Summit, July 29-30 |
| |
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.
[unhandled content-type:application/pgp-signature]
| |