On Mon, Jul 12, 2004 at 12:21:24PM +0200, Lars Marowsky-Bree wrote:
> On 2004-07-12T12:11:07,
>    Arjan van de Ven <arjanv@redhat.com> 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.

... which of course never allocates skb's ? ;)

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

there is more than swap, there's dirty pagecache/mmaps as well

> But again, I'd rather like to see this solved (memory pools for
> userland, PF_ etc), because it's relevant for many scenarios requiring

PF_ is not enough really ;) 
You need to force GFP_NOFS etc for several critical parts, and well, by
being in kernel you can avoid a bunch of these allocations for real, and/or
influence their GFP flags