--MGu/vTNewDGZ7tmp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 16, 2004 at 11:00:08AM +0200, Arto Selonen wrote:
> Hi!
>=20
> On Mon, 15 Nov 2004, Thor Lancelot Simon wrote:
>=20
> > On Mon, Nov 15, 2004 at 10:11:31PM +0200, Arto Selonen wrote:
>=20
> > > Well, page daemon is asking for something back, with the buf_drain() =
call
> > > after page scanning etc. However, in my case bufmem was >17,000 *page=
s*
>=20
> > I happen to believe that freetarg should be considerably higher on mode=
rn
> > large-memory systems.  Others may disagree; we seem to discuss it here
> > from time to time but come to no really good conclusion.
>=20
> Mmm. Another thing I forgot to mention about the buf_drain call in page
> daemon. When the call was before page scanning, doing
> "bufcnt=3Dfreetarg-free;buf_drain(bufcnt);" made sense. As in
> "we would like to guarantee at least freetarg, if buffer cache is still
> above lowater mark". Now that buf_drain call is after the scan, it
> seems to be merely to "excercise" buffer cache and get some memory back.
> Unless it is really useful to get different-sized drain requests, the
> whole bufcnt could be dropped, no? Whatever is released by buf_drain at
> that point is just memory to be used (by whoever needs it later), so
> why make precise calculations about the amount to be freed from bufcache?
>=20
> To use a low estimate of "freetarg-free", one could use freemin/2, leading
> to "we would like roughly 10% of freed memory to come from buffer cache,
> as everybody needs to give back some, and buffer cache is using ~15% of
> all", or use freemin as high estimate: "we would like roughly 20% ...". Of
> course, if BUFCACHE differs much from the default 15%, then this would
> lead to some bias.
>=20
> Yes, I understand nobody is going to touch the code over such a minor
> thing (especially since I could be way off here), but it is an observation
> I thought worth mentioning.

Please try the attached diff, which I have been using since we last
looked at all this issue earlier this year.

It doesn't affect the amount freed by the pagedaemon, as you note
above, but it changes the amount returned when something else is grown
via allocbuf.  Note that with the new arrangement of all MAX() values,
including a constant minimum term, it's at least possible that a new
allocation growing an existing buffer can in fact slightly reduce the
overall size of the buf cache.

I would be very interested to see how it affects your issue.

--
Dan.

--MGu/vTNewDGZ7tmp
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iD8DBQFBmo93EAVxvV4N66cRAlGdAJ92VTvnK3ufJAxGRcItTIlK/FWBQQCdEaZv
bNSZn7OrSYCKnT00tlIZ5Bc=
=kK3o
-----END PGP SIGNATURE-----

--MGu/vTNewDGZ7tmp--