Date: Thu, 3 Jan 2002 12:40:24 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: John Baldwin <jhb@FreeBSD.org> Cc: arch@FreeBSD.org, Bernd Walter <ticso@cicely8.cicely.de>, Mike Smith <msmith@FreeBSD.org>, Bruce Evans <bde@zeta.org.au>, Michal Mertl <mime@traveller.cz>, Peter Jeremy <peter.jeremy@alcatel.com.au> Subject: Re: When to use atomic_ functions? (was: 64 bit counters) Message-ID: <200201032040.g03KeOP72634@apollo.backplane.com> References: <XFMail.020103122607.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:> 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
<dillon@backplane.com>
: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 <jhb@FreeBSD.org> <>< 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200201032040.g03KeOP72634>