Date: Wed, 22 Jan 2003 15:03:05 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: bmilekic@unixdaemons.com Cc: sam@errno.com, bright@mu.org, arch@FreeBSD.ORG Subject: Re: M_ flags summary. Message-ID: <20030122.150305.79160884.imp@bsdimp.com> In-Reply-To: <20030122155457.A77036@unixdaemons.com> References: <20030122100253.A76397@unixdaemons.com> <0aef01c2c23d$0f1ae690$52557f42@errno.com> <20030122155457.A77036@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20030122155457.A77036@unixdaemons.com>
Bosko Milekic <bmilekic@unixdaemons.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030122.150305.79160884.imp>