From owner-freebsd-arch Tue Oct 31 16:27: 5 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id BC0CD37B479 for ; Tue, 31 Oct 2000 16:27:02 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eA10Qqg24508; Tue, 31 Oct 2000 16:26:52 -0800 (PST) (envelope-from dillon) Date: Tue, 31 Oct 2000 16:26:52 -0800 (PST) From: Matt Dillon Message-Id: <200011010026.eA10Qqg24508@earth.backplane.com> To: Terry Lambert Cc: bmilekic@dsuper.net (Bosko Milekic), tlambert@primenet.com (Terry Lambert), freebsd-arch@FreeBSD.ORG Subject: Re: MP: per-CPU mbuf allocation lists References: <200011010010.RAA19817@usr09.primenet.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> 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