On Mon, 13 Sep 1999, Garrett Wollman wrote:
!><<On Sun, 12 Sep 1999 23:19:13 -0400 (EDT), Bosko Milekic <[EMAIL PROTECTED]> said:
!>
!>> This message is in MIME format. The first part should be readable text,
!>> while the remaining parts are likely unreadable without MIME-aware tools.
!>> Send mail to [EMAIL PROTECTED] for more info.
!>
!>It would be preferable if text were sent as text, since MIME-encoded
!>patches require more effort to read.
!>
I deffinately agree. This is obviously my mistake, and I was
somewhat in a rush, very lagged (modem, eurgh), using pine, and made
several [dumb] typos in the 'Attatchement' field.
!>> I'm also aware of the possiblity of some people not liking the
!>> fact that we tsleep() forever (e.g. tsleep(x,x,x,0)).
!>
!>
!>I don't have any problem with sleeping forever -- but I am concerned
!>about the possibility of deadlock, especially when client-NFS is
!>involved. If the problem just moves around and has harder-to-recover
!>symptoms, the change isn't helping.
Well, the main purpose of the code is to basically sleep until
something is freed after we've already exhausted the mb_map arena (as I'm
sure you've seen if you were able to grab the attachements). This is
really a-la-limite stuff. In other words, if 'normal' local programs are
having trouble because of mb_map exhaustion, then maxusers && nmbclusters
would have to be augmented.
!>
!>The 4.3BSD code had two different behaviors:
!>
!> - For clusters, if M_WAIT was specified and there was no space
!>left in mb_map, it panicked. However, m_clalloc was never called with
!>M_WAIT, so that panic was effectively dead code.
Hmmm. If m_clalloc was never called with M_WAIT, then all the code
calling m_clalloc deffinately checked its return value. It probably had
specific ways to deal with m_clalloc returning failures, too?
!>
!> - For mbufs, if M_WAIT was specified and there were no mbufs
!>available, it would sleep at PZERO - 1 (which was interruptible).
!>
!>In 4.3, the code was able to deal with cluster allocation failing. We
!>have a somewhat different situation now, because many network
!>interface devices have less-flexible DMA mechanisms which don't allow
!>packet reception into non-contiguous buffers, so we need to have at
!>least a certain number of clusters available for this purpose.
Exactly. This is the next challenge. As for things being
interruptable, as I mentionned to a reply to Matt Dillon just a few
seconds ago, getting the tsleep to occasionally expire is trivial. As you
say above, it's dealing with the failure that is the issue.
!>
!>-GAWollman
!>
!>--
!>Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same
!>[EMAIL PROTECTED] | O Siem / The fires of freedom
!>Opinions not those of| Dance in the burning flame
!>MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick
!>
Cheers,
Bosko Milekic.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message