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

[Lars Marowsky-Bree]

On 2004-07-12T08:58:46,
   Arjan van de Ven <arjanv@xxxxxxxxxx> 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.)

Again, if we have "many" in kernel users requiring high performance &
low-latency, running in the kernel may not be as bad, but I still don't
entirely like it.

But user-space can also manage just fine, and instead continuing the "we
need highperf, low-latency and non-blocking so it must be in the
kernel", we may want to consider how to have high-perf low-latency
kernel/user-space communication so that we can NOT move this into the
kernel.

Suffice to say that many user-space implementations exist which satisfy
these needs quite sufficiently; in the case of a CFS, this argument may
be different, but I'd like to see some hard data to back it up.

(On a practical note, a system which drops out of membership because
allocating a 256 byte buffer for a filename takes longer than the node
deadtime (due to high load) is reasonably unlikely to be a healthy
cluster member anyway and is on its road to eviction already.)

The main reason why I'd like to see cluster infrastructure in the kernel
is not technical, but because it increases the pressure on unification
so much that people might actually get their act together this time ;-)


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/