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:3.051 / U:0.148 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site