From owner-freebsd-arch Wed Jan 22 14: 3:45 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 3E8BF37B401 for ; Wed, 22 Jan 2003 14:03:44 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CD3343EB2 for ; Wed, 22 Jan 2003 14:03:43 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.6/8.12.3) with ESMTP id h0MM3Y1e095136; Wed, 22 Jan 2003 15:03:35 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 22 Jan 2003 15:03:05 -0700 (MST) Message-Id: <20030122.150305.79160884.imp@bsdimp.com> To: bmilekic@unixdaemons.com Cc: sam@errno.com, bright@mu.org, arch@FreeBSD.ORG Subject: Re: M_ flags summary. From: "M. Warner Losh" In-Reply-To: <20030122155457.A77036@unixdaemons.com> References: <20030122100253.A76397@unixdaemons.com> <0aef01c2c23d$0f1ae690$52557f42@errno.com> <20030122155457.A77036@unixdaemons.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 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. : 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." : 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. : 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. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message