From owner-freebsd-arch Wed Jan 22 14:50:26 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5DCD37B401 for ; Wed, 22 Jan 2003 14:50:23 -0800 (PST) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id E788243F13 for ; Wed, 22 Jan 2003 14:50:22 -0800 (PST) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id h0MMpwt77439; Wed, 22 Jan 2003 17:51:58 -0500 (EST) (envelope-from bmilekic@unixdaemons.com) Date: Wed, 22 Jan 2003 17:51:58 -0500 From: Bosko Milekic To: "M. Warner Losh" Cc: sam@errno.com, bright@mu.org, arch@FreeBSD.ORG Subject: Re: M_ flags summary. Message-ID: <20030122175158.A77397@unixdaemons.com> References: <20030122100253.A76397@unixdaemons.com> <0aef01c2c23d$0f1ae690$52557f42@errno.com> <20030122155457.A77036@unixdaemons.com> <20030122.150305.79160884.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030122.150305.79160884.imp@bsdimp.com>; from imp@bsdimp.com on Wed, Jan 22, 2003 at 03:03:05PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jan 22, 2003 at 03:03:05PM -0700, M. Warner Losh wrote: > In message: <20030122155457.A77036@unixdaemons.com> > Bosko Milekic writes: > : am not religiously bound to doing it either way. However, I do think > : that leaving it as it is (with possibly defining M_WAIT{,OK} to 0 for > : KLD_MODULES) is the better thing to do. > > Actually, we wouldn't do that because it is stupid (kld and base > kernel having a different ABI). What we'd likely do instead is to > warn if sometimes if the old ABI was used. What the heck are you talking about? It wouldn't change the ABI, the ABI hasn't been changed. > : I realize that your idea of > : the interface is "it'll either block or not block," however when you > : think of the "new" approach don't think of it that way; rather, think > : of it as follows: "I am calling the allocator and it will do as much > : as it can to give me the resources I'm requesting (in the malloc() > : case, in fact, I'm sure it'll give me the resources I want or else > : block indefintely, in the mbuf allocator case it'll wait as long as > : I've configured it to wait - via a sysctl). I don't care what the > : allocator does. I am a thread executing in the kernel and let the > : allocator do whatever it takes to give me what I need." > > I think of it as "I'm calling the allocator, and I know it is safe to > block" or "I'm calling the allocator and I know it isn't safe to > block." It should always be safe to block unless you're in an ISR or unless you have code that is pretty whacked and that absolutely needs to hold on to a lock across an allocation. I'd prefer if we didn't encourage the latter, every time that you can wait (e.g. you're not in an ISR) and you don't take advantage of it, you lose. > : If you think of it that way you'll hopefully realize that it's no > : longer a question of whether or not to wait. Yes, we still provide a > : dontwait behavior, but in the new approach, that behavior is an > : _exception_, which is the way it should be. > > In your opinion. I differ that dontwait is the exceptional case, and > that it will always be the exceptional case in the future. Because you're thinking of bad design. > : As I said, your thoughts are important to me (and I'm sure to anyone > : else involved in this discussion) but I have yet to read an argument > : as to why the dontwait case _shouldn't_ be treated like the exception > : that it is in SMPng. > > The arguement against it is that you *SHOULD* be thinking about is it > OK to block here or not. I personally think the default should be to > no wait and return NULL because we don't want kernel threads blocking > by default. The more kernel threads block, the higher the latency you > introduce into those subsystems. We should only have them block when > they know that the latency for blocking is OK. What on earth are you talking about? "The more kernel threads block the higher latency you introduce?" That's totally non-sensical; how about you make EVERYTHING non-blocking then and let's just ditch blocking for resources altogether because it "increases latency?!" You're NOT increasing latency when you're blocking when you have nothing available. I really wish you considered what you're saying before you say it. I'm pretty sure that even the people who agree with what you want to do don't agree with some of the stuff you bring up here. > Warner Finally, I'm sick of arguing this. Just do whatever pleases you. -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message