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

On Thu, May 17, 2007 at 09:23:12PM -0700, Bill Stouder-Studenmund wrote:
> What I'm not sure about is what actually causes the upcalls to get=20
> processed. I see where we set the stack pointer and pc in the frame on=20
> return. So I readily see how ONE of these upcall stacks will get run. But=
=20
> what causes any others we generate to also run?

My murky understanding:

 Each of the upcall stacks is in a different libpthread thread, and
 the libpthread user-level scheduler is responsible for noticing these
 threads need to run and process an upcall.

 If the upcall in question tells libpthread that the lwp has been
 blocked, the upcall stack doesn't get recycled to process more
 upcalls until the lwp later unblocks.

 That later unblocking requires another upcall to be made. Although we
 send unlocked events in a batch, we may have run out of upcall frames
 to send that batch to, before something unlocked.

This leads to the problems described in
 http://mail-index.netbsd.org/tech-kern/2005/01/02/0001.html

I can't recall what was done to resolve this issue, if
anything, between when the message was written and when SA was
removed (or, more significantly, when -4 was rebranched).

Two suggestions were made in the reference email.  A third possibility
might be to rework the userlevel scheduler, such that the stack that
receives the SA_UPCALL_BLOCKED upcall can be recycled immediately,
rather than holding on to it until the LWP unblocks.  I have no idea
how the libpthread scheduler would be affected by this, or why it
behaves as it does in the first place, though.

--
Dan.


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

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

iD8DBQFGTTEPEAVxvV4N66cRApFoAKCsiX0oWUKFztqGMfeEI5NvL+oGdgCfV22B
+8cm0OyzR73breZ6G/Rnt64=
=xnC7
-----END PGP SIGNATURE-----

--ICrdrp3pM9DyZLTK--