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
> [EMAIL PROTECTED] | 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
[EMAIL PROTECTED] * http://www.technokratis.com/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
