Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 13 Sep 2000 17:16:12 -0700
From:      Alfred Perlstein <bright@wintelcom.net>
To:        Bosko Milekic <bmilekic@dsuper.net>
Cc:        freebsd-net@FreeBSD.ORG
Subject:   Re: Clusters larger than PAGE_SIZE and contigmalloc()
Message-ID:  <20000913171611.E12231@fw.wintelcom.net>
In-Reply-To: <Pine.BSF.4.21.0009132006490.8861-100000@jehovah.technokratis.com>; from bmilekic@dsuper.net on Wed, Sep 13, 2000 at 08:13:05PM -0400
References:  <Pine.BSF.4.21.0009132006490.8861-100000@jehovah.technokratis.com>

next in thread | previous in thread | raw e-mail | index | archive | help
* Bosko Milekic <bmilekic@dsuper.net> [000913 17:10] wrote:
> 
>   Hi,
> 
>   	With the recent cleanups and SMP work that I'm involved with
>   revolving around mbufs and friends, I feel that it's about the time to
>   raise this issue.
> 
>   	I'd like to know:
> 
> 	Are there any people out there using the "large cluster" feature
>   (i.e. manually defining the cluster size, MCLBYTES, to be larger than
>   a PAGE_SIZE?) If so, how useful do you find this? Did you stumble across
>   any problems worth mentionning?

Well I attempted to use clusters larger than PAGE_SIZE without
contigmalloc not realizing that there was no bus_space_foo for
mbufs.  It wasn't fun debugging that.  Mike Smith suggested that
I investigate how NetBSD handles this situation, I looked and it
seemed somewhat ok, but at a glance somewhat inneficient.

>   	I'm wondering if it would be worth just scrapping this code, as
>   contigmalloc() doesn't help us in this case much anyway, and since most,
>   if not all of the code, that needs such a feature maintains its own free
>   lists and has its own allocator, which is somewhat more efficient as it
>   pre-allocates all of the required space while attaching (the last time I
>   checked). contigmalloc() may have trouble finding the required
>   contiguous physical pages after a certain period of uptime. I would
>   assume that when this was initially written that it was real nice to have
>   around, but I'm not sure if this is still the correct approach for
>   reaching our present goals.

Well, if you could do the bus space stuff for mbufs that would be
optimal, I'm sure the ethernet driver authors wouldn't have much
trouble migrating over to it.

-Alfred


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000913171611.E12231>