mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®