Messages in this thread | | | Date | Wed, 21 Dec 2005 10:11:14 +0100 | From | Pavel Machek <> | Subject | Re: [RFC][PATCH 0/3] TCP/IP Critical socket communication mechanism |
| |
Hi!
> > If it is only one place, why not pre-allocate one "I'm sick now" > > skb and hold onto it. Any bigger solution seems to snowball into > > a huge mess. > > But the problem is even sending/receiving a single packet can cause > multiple dynamic allocations in the networking path all the way from > the sockets layer->transport->ip->driver. > To successfully send a packet, we may have to do arp, send acks and > create cached routes etc. So my patch tried to identify the allocations > that are needed to succesfully send/receive packets over a pre-established > socket and adds a new flag GFP_CRITICAL to those calls. > This doesn't make any difference when we are not in emergency. But when > we go into emergency, VM will try to satisfy these allocations from a > critical pool if the normal path leads to failure. > > We go into emergency when some management app detects that a swap device > is about to fail(we are not yet in OOM, but will enter OOM soon). In order > to avoid entering OOM, we need to send a message over a critical socket to > a remote server that can initiate failover and switch to a different swap > device. The switchover will happen within 2 minutes after it is initiated. > In a cluster environment, the remote server also sends a message to other > nodes which are also running the management app so that they also enter > emergency. Once we successfully switch to a different swap device, the remote > server sends a message to all the nodes and they come out of emergency. > > During the period of emergency, all other communications can block. But > guranteeing the successful delivery of the critical messages will help > in making sure that we do not enter OOM situation.
Why not do it the other way? "If you don't hear from me for 2 minutes, do a switchover". Then all you have to do is _not_ to send a packet -- easier to do.
Anything else seems overkill. Pavel -- Thanks, Sharp! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |