From owner-freebsd-hackers Mon Jul 3 12:26:37 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id 03FA537BF8F for ; Mon, 3 Jul 2000 12:26:33 -0700 (PDT) (envelope-from bmilekic@dsuper.net) Received: from modemcable009.62-201-24.mtl.mc.videotron.net ([24.201.62.9]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0FX4001BEYYIMK@falla.videotron.net> for freebsd-hackers@FreeBSD.ORG; Mon, 3 Jul 2000 15:18:18 -0400 (EDT) Date: Mon, 03 Jul 2000 15:20:22 -0400 (EDT) From: Bosko Milekic Subject: Re: mbuf re-write(s), v 0.1 In-reply-to: <7941.962650295@critter.freebsd.dk> X-Sender: bmilekic@jehovah.technokratis.com To: Poul-Henning Kamp Cc: freebsd-hackers@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 3 Jul 2000, Poul-Henning Kamp wrote: > Considering the prominence of DoS attacks and similar, I think it > makes a lot of sense to be able to free the memory again, and if > the hysteresis you have built in means that there is no measurable > performance impact I think you will face no objections. That was one of the reasons of writing. Oh, and there's something I forgot to mention previously. The code I presently have frees memory dedicated to mbufs, so obviously, it's significant, but it's even more significant in the case of mbuf clusters, as they are larger. I still haven't finished writing the cluster stuff though but expect it to be similar in concept and design. > Is it possible to auto-tune min_on_avail somehow ? > > What if instead you made it free only when more than 50% of the > memory allocated from the map was unused ? min_on_avail is presently a sysctl but I do expect to have it optionally autotuned - read below. > Could that freeing be done by a timeout routine which runs every > N seconds ? Ah! Finally, you've read my mind! The design has been made with the idea of the possibility of a "kernel process" running [optionally] periodically which will take care of such issues. * reducing fragmentation by moving page descriptor structure nodes with almost complete free lists to the bottom of the "free" doubly-linked list * possible auto-tuning of min_on_avail; I will be expanding mbstat to include allocator statistics, so that the number of times the VM allocation routine and the VM free routine have been called can be recorded and used for such purposes. * drain routine to free pages back to VM system In other words, the free page back to mb_map routine takes as an argument a node on the free list, so the "timeout" daemon can be made to walk the free list and pick out full available pages from the list and return the space to the map, on the condition that min_on_avail is respected. The issue with doing this however is that it will have to splimp() while walking the lists, so the issue being with whether it's really much of an advantage (as opposed to freeing from MFREE if necessary). On the other hand, what I think would be more of an advantage is having MFREE only call m_mbmapfree() [the new free routine] if (how) == M_WAIT. If (how) == M_NOWAIT, then the mbuf will just be attached to its corresponding page descriptor's free chain. I try to take advantage of (how) being M_WAIT as much as possible. For instance, during allocation, even if the free list is not empty but (how) is M_WAIT, the system will still fetch a new page and allocate from it if the number of free mbufs are less than min_on_avail. This is to minimize the calling to m_mbmapalloc() when allocations are to be done with M_NOWAIT (i.e. from interrupts). > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD coreteam member | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. -- Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237 bmilekic@technokratis.com * http://www.technokratis.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message