From: Matti Aarnio <matti.aarnio@zmailer.org>
To: Dennis <dennis@etinc.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: SMP in 2.4
Date: Wed, 18 Apr 2001 21:05:46 +0300 [thread overview]
Message-ID: <20010418210546.W805@mea-ext.zmailer.org> (raw)
In-Reply-To: <20010418211208.A1140@villain.home.ems.chel.su> <5.0.2.1.0.20010418110702.03850d20@mail.etinc.com>
In-Reply-To: <5.0.2.1.0.20010418110702.03850d20@mail.etinc.com>; from dennis@etinc.com on Wed, Apr 18, 2001 at 11:08:22AM -0400
On Wed, Apr 18, 2001 at 11:08:22AM -0400, Dennis wrote:
> Does 2.4 have something similar to spl levels or does it still require the
> ridiculous MS-DOSish spin-locks to protect every bit of code?
Lets see -- (besides of MSDOS not having any sort of spinlocks), the
spl() is something out of VAX series of machines, and it really works
by presuming that there is some sort of priority leveling among irq
sources.
At i386 there is only one level of interrupt control, either you
accept interrupts, or you don't. It just doesn't scale very well.
At FreeBSD site there is no documentation of how to handle interrupts,
presumably that is "read the source, luke".
Ah, found some man-page with its description..
Essentially the supported function for spl() is:
spin_lock_irqsave(&sp->lock, flags);
along with its counterpart ( splx() ):
spin_unlock_irqrestore(&sp->lock, flags);
These block interrupts at the LOCAL processor only (no interprocessor
communication hazzle for it), and the spinlocks are for blocking
interrupt processing by *other* processors at SMP systems.
( Linux does distribute interrupts these days to *all* processors
when APIC is in use, and while it is fast and easy to block IRQ
at local processor, getting other processors also to block IRQs
is major slow thing... )
At UP systems the SAME functions are used, but their internal
implementations are slightly different -- no SMP related spinlock
is operated.
For a model, see drivers/net/eepro100.c
> DB
next prev parent reply other threads:[~2001-04-18 18:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-18 15:12 2.4.3 - Kernel panic Aleksey I Zavilohin
2001-04-18 15:08 ` SMP in 2.4 Dennis
2001-04-18 16:21 ` Mark Hahn
2001-04-18 17:00 ` Richard B. Johnson
2001-04-18 18:05 ` Matti Aarnio [this message]
2001-04-18 22:44 ` Dennis
2001-04-20 23:53 ` Mikulas Patocka
2001-04-21 0:16 ` Alan Cox
2001-04-21 9:08 ` Mikulas Patocka
2001-04-21 9:50 ` Alan Cox
2001-04-21 11:41 ` Mikulas Patocka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010418210546.W805@mea-ext.zmailer.org \
--to=matti.aarnio@zmailer.org \
--cc=dennis@etinc.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®