Date: Wed, 23 Oct 2002 16:51:44 -0400 (EDT) From: Jeff Roberson <jroberson@chesapeake.net> To: Seigo Tanimura <tanimura@axe-inc.co.jp> Cc: Bruce Evans <bde@zeta.org.au>, <current@FreeBSD.ORG>, <tanimura@FreeBSD.ORG> Subject: Re: Dynamic growth of the buffer and buffer page reclaim Message-ID: <20021023163758.R22147-100000@mail.chesapeake.net> In-Reply-To: <200210230935.g9N9ZgoK086922@shojaku.t.axe-inc.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 23 Oct 2002, Seigo Tanimura wrote: > On Wed, 23 Oct 2002 16:44:06 +1000 (EST), > Bruce Evans <bde@zeta.org.au> said: > > Incidentally, Solaris 7 on sun4u reserves a space of 256MB in the KVM > according to Solaris Internals. On i386 (x86), the size is only 4MB. > Not sure whether they use those spaces in a pure form, or they cluster > some consecutive pages (which leads to fragmentation), though... > > NetBSD UBC also makes a map dedicated to buffers in kernel_map. > > Maybe there is a point to have a map dedicated to the buffer space for > a better stability, and the size of the buffer map could be much > smaller than now. During my testing, I found that only up to 6-7MB of > the buffers out of 40-50MB were wired down (ie busy, locked for > background write or dirty) at most. > I was going to comment on fragmentation issues, but that seems to have been very well covered. I would like to point out that removing the buffer_map not only contributes to kernel map fragmentation, but also contention for the kernel map. It might also prevent us from removing giant from the kernel map because it would add another interrupt time consumer. I do, however, like the page unwiring idea. As long as it's not too expensive. I have been somewhat disappointed that the buffer cache's buffers are hands off for the vm. I'm confused about your approach though. I think that the rewire function is unnecessary. You could move this code into allocbuf() which would limit the number of times that you have to make a pass over this list and keep the maintenance of it in a more central place. This would also remove the need for truncating the buf. I have some other ideas for the buffer cache that you may be interested in. I have been discussing them in private for some time but I'll bring it up on arch soon so that others can comment. Cheers, Jeff 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?20021023163758.R22147-100000>