Messages in this thread | | | Date | Mon, 12 Jul 2004 12:28:19 +0200 | From | Arjan van de Ven <> | Subject | Re: [ANNOUNCE] Minneapolis Cluster Summit, July 29-30 |
| |
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 [unhandled content-type:application/pgp-signature] | |