Date: Tue, 31 Oct 2000 16:26:52 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Terry Lambert <tlambert@primenet.com> Cc: bmilekic@dsuper.net (Bosko Milekic), tlambert@primenet.com (Terry Lambert), freebsd-arch@FreeBSD.ORG Subject: Re: MP: per-CPU mbuf allocation lists Message-ID: <200011010026.eA10Qqg24508@earth.backplane.com> References: <200011010010.RAA19817@usr09.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> Is this 100% accurate? Don't we still need to protect even the
:> per-CPU lists with a lock just in case we get an interrupt and get
:> rescheduled because of a higher priority thread that wants execution? Is
:> this possible?
:
:Are you assuming kernel threads with kernel preemption in interrupt
:context? If so, why? Kernel threads make interrupt processing
:times non-deterministic, so it's not like you could build a hard
:real time system with them in there: HRT needs determinism, or you
:can't do scheduling or deadlining.
:
:If you don't have HRT requirements, why do you need kernel
:preemption?
Keep in mind, guys, that the purpose is to avoid cache conflicts between
cpu's. Having a per-cpu spinlock to protect a per-cpu list against
preemption is perfectly acceptable, and very *VERY* fast not only because
the cpu owns the cache line, but also because you don't have to bother
with locked bus cycles (since the lock is per-cpu).
-Matt
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?200011010026.eA10Qqg24508>