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

[Lars Marowsky-Bree]

On 2004-07-12T12:11:07,
   Arjan van de Ven <arjanv@xxxxxxxxxx> said:

> 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.

Sure, but the network IO is isolated from the main process via a _very
careful_ non-blocking IO using sockets library, so that works out well.
The only scenario which could still impact this severely would be that
the kernel did not schedule the soft-rr tasks often enough or all NICs
being so overloaded that we can no longer send out the heartbeat
packets, and some more silly conditions. In either case I'd venture that
said node is so unhealthy that it is quite rightfully evicted from the
cluster. A node which is so overloaded should not be starting any new
resources whatsoever.

However, of course this is more difficult for the case where you are in
the write path needed to free some memory; alas, swapping to a GFS mount
is probably a realllllly silly idea, too.

But again, I'd rather like to see this solved (memory pools for
userland, PF_ etc), because it's relevant for many scenarios requiring
near-hard-realtime properties, and the answer surely can't be to push it
all into the kernel.


Sincerely,
    Lars Marowsky-Brée <lmb@xxxxxxx>

-- 
High Availability & Clustering	    \ ever tried. ever failed. no matter.
SUSE Labs, Research and Development | try again. fail again. fail better.
SUSE LINUX AG - A Novell company    \ 	-- Samuel Beckett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/