:...
:> What was previously done at some point was use the kernel malloc() to
:> allocate mbufs. As you know, this is a general purpose allocator that has
:> to first determine what algorithm to use and then store the object
:> correctly according to its size. This allocator is faster than
On Thu, 6 Jul 2000, Bosko Milekic wrote:
> I've recently had the chance to get some profiling done.
>
> I used metrics obtained from gprof, as well as the (basic block
> length) * (number of executions) metric generated by kernbb. The latter
> reveals an approximate 30% increase
On Mon, 3 Jul 2000, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Bill Fumerola writes:
>
> >I'd love to have FreeBSD be able to reclaim memory quicker at the sacrifice
> >of a few cpu cycles. Why? Well, the "add more memory" arguement doesn't work
> >well when I get DoS attacks th
In message <[EMAIL PROTECTED]>, Bill Fumerola writes:
>I'd love to have FreeBSD be able to reclaim memory quicker at the sacrifice
>of a few cpu cycles. Why? Well, the "add more memory" arguement doesn't work
>well when I get DoS attacks that will eat any memory available because they
>can connec
On Mon, Jul 03, 2000 at 03:20:22PM -0400, Bosko Milekic 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
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 o
In message <[EMAIL PROTECTED]>, B
osko Milekic writes:
> When I posted the initial diff, I provided such data. I'll repeat: a
> good example is at: http://24.201.62.9/stats/mbuf.html
Considering the prominence of DoS attacks and similar, I think it
makes a lot of sense to be able to free
On Mon, 3 Jul 2000, David Greenman wrote:
>What I'm doing is challenging your assertions that spending CPU cycles to
> save memory in the networking code is the right thing to do. I'm further
> saying that I have direct experiance in this area since I'm one of the primary
> people in FreeBSD
* Jeroen C. van Gelderen <[EMAIL PROTECTED]> [000703 08:52] wrote:
> Alfred Perlstein wrote:
>
> > Sacrificing performance to fix the small occurances where
> > this is not the case is not worth it, the general case will always
> > be there and will be more important.
>
> You seem to imply that
Alfred Perlstein wrote:
>
> * David Greenman <[EMAIL PROTECTED]> [000703 01:32] wrote:
>
> .. response to mbuf rewrite
>
> >I'm not trying to 'frown upon evolution', unless the particular form of
> > evolution is to make the software worse than it was. I *can* be convinced
> > that your pro
* David Greenman <[EMAIL PROTECTED]> [000703 01:32] wrote:
.. response to mbuf rewrite
>I'm not trying to 'frown upon evolution', unless the particular form of
> evolution is to make the software worse than it was. I *can* be convinced
> that your proposed changes are a good thing and I'm as
In message <[EMAIL PROTECTED]>, David Greenman writes:
>> I'm getting the unfortunate impression that evolution is being
>> frowned upon here. Are their other people that frown the proposal out
>> there to this extent? (i.e. "don't change it if it works") I'd like to
>> hear some important
> I'm getting the unfortunate impression that evolution is being
> frowned upon here. Are their other people that frown the proposal out
> there to this extent? (i.e. "don't change it if it works") I'd like to
> hear some important voices on this issue so that I can decide whether to
> j
In message <[EMAIL PROTECTED]>,
Bosko Milekic writes:
> I'm getting the unfortunate impression that evolution is being
> frowned upon here. Are their other people that frown the proposal out
> there to this extent? (i.e. "don't change it if it works") I'd like to
> hear some important v
On Sun, 2 Jul 2000, David Greenman wrote:
>Yes, malloc is slow for other reasons, but it is especially slow when VM
> pages are freed back to the general pool. Of course it is possible to
> introduce hysteresis in the algorithm such that it doesn't free the pages as
> often, but this (and al
>On Thu, 29 Jun 2000, David Greenman wrote:
>
>>We used to do this in FreeBSD, but found that it was a bad idea for
>> performance reasons. Freeing and reallocating memory from the high-level
>> VM system is quite expensive and the trend in NICs these days is towards
>> needing the code to be
On Thu, 29 Jun 2000, Joe McGuckin wrote:
>
> What about a slab allocator
> (e.g. http://www.cnds.jhu.edu/~jesus/418/SlabAllocator.pdf)
>
> Joe
What's your motivation behind this recommendation?
What you're essentially suggesting is a replacement for our kernel
malloc(). Th
* Joe McGuckin <[EMAIL PROTECTED]> [000629 15:23] wrote:
>
> What about a slab allocator
> (e.g. http://www.cnds.jhu.edu/~jesus/418/SlabAllocator.pdf)
Which completely fails to address the concepts behind mbufs.
-Alfred
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd
What about a slab allocator
(e.g. http://www.cnds.jhu.edu/~jesus/418/SlabAllocator.pdf)
Joe
Bosko Milekic <[EMAIL PROTECTED]> wrote:
>
> On Thu, 29 Jun 2000, David Greenman wrote:
>
> >We used to do this in FreeBSD, but found that it was a bad idea for
> > performance reasons. Freeing a
On Thu, 29 Jun 2000, David Greenman wrote:
>We used to do this in FreeBSD, but found that it was a bad idea for
> performance reasons. Freeing and reallocating memory from the high-level
> VM system is quite expensive and the trend in NICs these days is towards
> needing the code to be even
> In an attempt to eliminate or significantly reduce the hogging of
> physical memory by unused mbufs, I have begun re-writing some of the mbuf
> subsystem. I've re-written the allocator and designed an actual free
> routine, and have also considerably re-written the MGET, MGETHDR, and
>
In an attempt to eliminate or significantly reduce the hogging of
physical memory by unused mbufs, I have begun re-writing some of the mbuf
subsystem. I've re-written the allocator and designed an actual free
routine, and have also considerably re-written the MGET, MGETHDR, and
MF
22 matches
Mail list logo
