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