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

On Thu, May 13, 2004 at 11:48:50AM -0400, Thor Lancelot Simon wrote:
> The interaction of the new metadata cache and the page cache seems to lead
> to significant kernel memory fragmentation.  Because most requests from
> the metadata cache are small, larger regions of free memory are split up;
> when the metadata cache returns memory, it does so one buffer at a time
> (typically just one or two pages) and this means that even when we have
> quite a bit of memory free, very little of it may be contiguous.  This
> causes problems for drivers like the USB drivers and the drivers for
> various cardbus cards.

Hm. Indeed.

> As an experiment, if you're having "can't allocate..." problems with
> such a driver, try removing the device in question, reducing
> vm.bufmem_hiwater significantly, and running something that allocates,
> then frees a good-zies hunk of memory.  You will probably then find that
> you can reconnect the device and everything will work fine.

I find this works even without needing to bash the sysctl:

  dd if=3D/dev/zero of=3D/dev/null bs=3D<about 3/4 of ram size> count=3D2
=20
> I'm not sure how to address this issue.  I'd love to hear ideas.

It might be that a statistical approach is enough to help out;
something like malloc hints that could bias allocations for the page
cache to higher addresses and bufcache to lower addresses?

--
Dan.

--L2YZAWjVjAQ1Un1Q
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFApA9lEAVxvV4N66cRAq48AJ9BO7Ws7TDK7aLsDrv9LorJuq8Z5ACg7rzk
BPBiNTG2CyPQu9HbXsWFVJI=
=Pxtg
-----END PGP SIGNATURE-----

--L2YZAWjVjAQ1Un1Q--