--yrj/dFKFPuw6o+aM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello,

since I've upgraded to NetBSD-1.6_STABLE as of this weekend, I'm running
into l1ptwait much more often than before.

I've increased PMAP_STATIC_L1S to 128 and still get one or three per evenin=
g.

This is pretty annoying, as the only way out is to make sure some process
is killed, like, pressing q on top.

I noted that the l1pt allocatioln strategy is:

1. try the static list
2. try if we have a free dynamically allocated one on the free list
3. if this fails, try to allocate one.

(Freed dynamic l1pt go to 2. unless it has already 8, then theyre just freed
to their pool.)

Now, the problem we're trying to solve is that the arm cpu need contiguous
physical 16k (4 pmap pages), naturally aligned if I recall correctly, in
addition to VM resources to make them accessible to the kernel, per l1pt.

Wouldn't the wiser strategy be:

1. try if we have a free one on the l1pt free list
2. if this fails, try to allocate a new one
3. if this still fails, go to the static list?

This way, we only go to the static list if memory is fragmented or if we
run out of memory...

Would this fail during bootstrap? As the machine in question is my producti=
on
server, I don't want to waste time trying stupid things...

The only alternative to make this pmap stable would be to use a VAX-like
16kB VM pages with 4KB mmu pages strategy, which naturally ensures that we
never run out of aligned 16kB blocks.


Regards,
	-is

--=20
seal your e-mail: http://www.gnupg.org/

--yrj/dFKFPuw6o+aM
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE95bk4PCRcZ/VMtk4RAgucAJ4shUAINEUBo4H540n9XC8BKnsUTACfRJRX
hsGTn1bmggaULoiOfL2F80M=
=gArq
-----END PGP SIGNATURE-----

--yrj/dFKFPuw6o+aM--