lkml.org 
[lkml]   [2004]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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]
\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.105 / U:0.648 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site