From owner-freebsd-arch Sun Dec 3 13:25:46 2000 From owner-freebsd-arch@FreeBSD.ORG Sun Dec 3 13:25:44 2000 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id B1CF437B400 for ; Sun, 3 Dec 2000 13:25:43 -0800 (PST) Received: from modemcable213.3-201-24.mtl.mc.videotron.ca ([24.201.3.213]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G5000NB5GUP0H@field.videotron.net> for arch@FreeBSD.ORG; Sun, 3 Dec 2000 16:25:38 -0500 (EST) Date: Sun, 03 Dec 2000 16:26:26 -0500 (EST) From: Bosko Milekic Subject: Re: zero copy code review In-reply-to: <200012032006.NAA00585@usr05.primenet.com> To: Terry Lambert Cc: dg@root.com, Andrew Gallatin , "Kenneth D. Merry" , arch@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 3 Dec 2000, Terry Lambert wrote: [...] > There's a real easy fix for this: > > > m_get_not_broken( flag, type) > int flag, type; > { > struct mbuf *m; > > do { > m = m_get( flag, type); > } while( flag == M_WAIT && m == NULL); > > return( m); > } > > I think the idea that the M_WAIT flag should be broken so that > it can be safely used in interrupt mode is dumb. I'm not sure I understand what you're putting forward with the above comment, specifically what you're referring to when you say "broken." Are you trying to say that "M_WAIT is broken because it doesn't wait forever?" If that's what you're trying to say, the explanation is simple. If you "wait indefinetely," or spin as you're doing above, then what you're doing is pretty much useless. Let me explain why and how you can test my hypothesis without changing a single line of code. First of all, the amount of time spent waiting with M_WAIT is completely tunable with the kern.ipc.mbuf_wait sysctl. If you want to wait indefinetely, just set it to 0. Second of all, the default value is 32. The reason for that is that it is typically sufficient if you're going to get anything in the first place. Basically, if you're short on mbufs and you're hoping one will be freed then, in the general case (I've established this through various testing), on a relatively generic machine, with moderately heavy network load, you're going to get one back within the 32 ticks. If it isn't sufficient, you can tune from 32 to 64 to whatever it is you feel is appropriate. The only case where you won't be getting back what you need in the default time, usually, is when the main mbuf consumer is a process which is, in effect, sucking up all resources (allocating them for itself) -- think local DoS. In that case, even after you wait 32 ticks, 64 ticks, or infinity ticks, you're likely to not get anything and even if you happen to get ONE mbuf, then it's even worse 'cause all that's happened is that the offending process has swallowed yet another mbuf and prevented the other (essential) system components to allocate. So, in the latter case, if you have a non-offending process calling sendfile(2) and trying to allocate an mbuf, it can wait all day if you want it to, and it will never get anything until the offending process is killed. So, better to have the process return from the kernel and deal with the temporary failure. The same goes for the offending process that will keep exhausting mbufs in a tight loop; think of what would happen once the offending process hits the hard limit and exhausts mbufs. It will just be stuck waiting/looping indefinetely in the kernel and will not be killable because it will not be able to receive any signals posted to it until it returns from the kernel. Basically, what I'm telling you is: M_WAIT behavior is not broken in FreeBSD, it is entirely tunable and it is better, in the general case, to NOT have M_WAIT mean 'wait indefinetely.' > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. Regards, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message