From owner-freebsd-security Sun Jan 23 19:40:20 2000 Delivered-To: freebsd-security@freebsd.org Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by hub.freebsd.org (Postfix) with ESMTP id 8A23114FFC for ; Sun, 23 Jan 2000 19:40:15 -0800 (PST) (envelope-from bmilekic@dsuper.net) Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by oracle.dsuper.net (8.9.3/8.9.3) with ESMTP id WAA27923; Sun, 23 Jan 2000 22:39:50 -0500 (EST) Date: Sun, 23 Jan 2000 22:39:50 -0500 (EST) From: Bosko Milekic To: Warner Losh Cc: Peter Jeremy , Darren Reed , freebsd-security@FreeBSD.ORG Subject: Re: kernel panic's still due to mbuf problems. In-Reply-To: <200001240214.TAA47946@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 23 Jan 2000, Warner Losh wrote: >In message <00Jan24.125351est.115220@border.alcanet.com.au> Peter Jeremy writes: >: This subject has been discussed regularly and so far, no-one has >: managed to produce a solution which does not entail a significant >: performance hit. It's generally accepted that the current behaviour >: is undesirable and if you have real solution to offer, I'm sure >: it'll be gratefully accepted. > >I'm working on that... > Well, then. Would you be willing to share on exactly what aspect you're working on? I'm presently designing/writing a quasi-load balancing system for local processes. The idea will probably result in a `mbufd' kernel thread/daemon which will work with a list to which processes which have opened (a) socket(s) will be hung off of. Each entry in the list will build its own "horizontal" socket list. As this all grows, when mbufs and clusters become significantly limited, the thread would be woken and would close sockets belonging to certain processes, thus resulting in flushing the sockbuf space for the socket in question. In this situation, a system will have to be devised where the load is spread out evenly, therefore not permitting a single process to hold on to mbufs or mclusters for too long, when something else needs it. Remember, this would only be triggered when *low* in network memory resources. A wise administrator would ensure that sockbuf limiting is in place anyway, and this would be a last-hope solution (better than just killing processes off). More discussion will have to be done for what concerns the clean closure of the sockets, obviously. I already have the x-y lists and the thread written, but the main and most significant portion of the work still remains to be designed/written (aside from all the gory performance details for what concerns searching and tinkering with the x-y lists above). Now, if you're writing something else, I'd be very curious to hear about it, since it can (and probably will) affect whatever I'm already playing with -- if you don't mind. :-) -Bosko. -- Bosko Milekic Email: bmilekic@dsuper.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message