Date: Mon, 25 May 1998 13:11:41 +0800 From: Peter Wemm <peter@netplex.com.au> To: dyson@FreeBSD.ORG Cc: dima@xyzzy.machaon.ru (Dmitry Khrustalev), peter@FreeBSD.ORG, current@FreeBSD.ORG, dima@bog.msu.su Subject: Re: cvs commit: src/sys/nfs nfs.h nfs_node.c nfs_nqlease.c nfs_subs.c nfs_vfsops.c Message-ID: <199805250511.NAA19722@spinner.netplex.com.au> In-Reply-To: Your message of "Sun, 24 May 1998 15:03:12 EST." <199805242003.PAA02028@dyson.iquest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
"John S. Dyson" wrote:
> Dmitry Khrustalev said:
> > I'm not sure this is a good idea. Memory allocated from zone is never retur
ned
> > to the system. There could be periods of high NFS activity and periods of n
o
> > NFS activity at all when this allocation of wired kernel memory would be
> > wasted.
> >
> The malloc pool only grows (in the case of sub-page size allocations) also.
> The difference is that the zone pool is managed per data item type, while
> the malloc pool is managed per size. There IS a tradeoff, but I have found
> that the lossage of using zone vs. malloc is small in most cases.
>
> One advantage of zone is that the allocation is very very fast, even
> with stats gathering. Additionally, there is less internal fragmentation.
Perhaps we should do some sort of periodic reclaim of unused zone pages? I
was planning on moving some of the other nfs structs to zones as well,
especially those that are allocated and freed by the tens or hundreds of
thousands of times per "busy" session (eg: doing a cvs update over nfs).
The 'never freed' bit worrys me a little since these can be busty and
temporarily larger than usual. The speed of zone based allocation will be
nice here, since one one machine that's been running with some nfs activity
over a day or two has clocked up 300K requests for a 64 byte object, and
yet the high water mark is only 1KB. I'd be happy to trade an entire page
to supercharge that. :-)
Cheers,
-Peter
--
Peter Wemm <peter@netplex.com.au> Netplex Consulting
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805250511.NAA19722>