From owner-freebsd-arch Thu Jan 3 12:40:28 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 96E9537B405; Thu, 3 Jan 2002 12:40:24 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g03KeOP72634; Thu, 3 Jan 2002 12:40:24 -0800 (PST) (envelope-from dillon) Date: Thu, 3 Jan 2002 12:40:24 -0800 (PST) From: Matthew Dillon Message-Id: <200201032040.g03KeOP72634@apollo.backplane.com> To: John Baldwin Cc: arch@FreeBSD.org, Bernd Walter , Mike Smith , Bruce Evans , Michal Mertl , Peter Jeremy Subject: Re: When to use atomic_ functions? (was: 64 bit counters) References: 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 :> When an interrupt actually *occurs*, interrupts are disabled by the :> processor. So I don't see why there would be any problem obtaining :> the ICU lock inside the interrupt itself. Again, it's exactly the same :> problem the spl*() code has - that part of the interrupt runs outside :> Giant in -stable too you know. : :Err, what if the top-half code you are interrupting already holds the ICU lock. :What then? You either panic cause the lock isn't recursive, or you corrupt :your ICU if you let the lock recurse. Maybe you need to give me an example of a possible real-life scenario. I just don't see the problem. ICU manipulation does not occur in the normal code path, so it is no big deal to disable interrupts for real if we have to occassionally do it outside the interrupt code itself. :> reduced the potential performance of the code by introducing a :> conditional that some architectures (e.g. i386) can do without. : :Read what I said. The routines will get larger. Also, they are spread across :2 files right now: kern/kern_switch.c and machine/cpufunc.h. By about two lines of code. There is also a prototype in sys/systm.h though I suppose one could ignore that. Ok, two files... but one is MD and one is MI. The actual function is still split unnecessarily. Even my implementation would be in two files, since I would want to optimize with inlines, but they would be entirely within the MD section of the system. :> :> I disagree. You can implement the same concept on Alpha too if you want. :> I am not an Alpha assembly programmer so I can't do it, but I sure as :> hell can fix i386. If someone cares about the Alpha enough there is :> nothing stopping them from doing thet same optimization for the alpha. : :You are missing the point. You are looking at the world as if all machines :work like a 386. They _don't_. When you design things, you have to take into :account other architectures. No I am not. I am stating that the concept of a deferred interrupt works on any architecture, and that we can guarentee certain performance characteristics by designing an API around that concept. It is no different from the lowest-common-denominator concept you are using except that it is far more flexible in regards to implementation details and it can guarentee far better performance across a wider range of platforms then what you have in there now. :That comes from someone who only works on cares about one arch. :) Sigh. Look, just because I only know I386 (and 68000, and 6502, and 808x, and a few others) doesn't mean that I have my head in the ground. I am perfectly well aware of how other cpus are designed, I know how other archs work, and I am easily as qualified as you are in that regard. Just because I'm not an expert assembly programmer for three major architectures does not invalidate my opinion. -Matt Matthew Dillon :Anyways, I think we aren't completely opposed to each other. Lazy disabling of :interrupts would work and wouldn't really cost much since by the time we do it :we have already taken an interrupt. The lazy interrupt disabling would also :work on all the platforms we currently support and I think should work on ones :in the future. It also doesn't need any locks in the bottom half which is a :critical feature. Note that not having locks does place some restrictions: we :can't use a list embedded in struct ithd since bad things can happen if the :same interrupt goes to two CPU's at the same time when both are in critical :sections. Tbus, we allow one interrupt then leave interrupts disabled until we :exit the section. Secondly, CPU's can't steal pending interrupts from each :other since that would need a lock. : :-- : :John Baldwin <>< http://www.FreeBSD.org/~jhb/ :"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message