mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Phillip Susi <psusi@cfl.rr.com>
To: Robert Love <rml@tech9.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] (Updated) Preemptible Kernel
Date: Thu, 6 Sep 2001 20:39:25 +0000	[thread overview]
Message-ID: <200109070046.f870kEM06465@smtp-server2.tampabay.rr.com> (raw)
In-Reply-To: <999813729.2039.9.camel@phantasy>
In-Reply-To: <999813729.2039.9.camel@phantasy>

This sounds interesting, but am I correct in assuming that this only allows 
preemption during code that is called from user space?  For instance, it 
would be bad to preempt an ISR or BH, right?  Actually... what happens if 
say, the kernel called from user space is holding a lock, and gets preempted? 
 Is there a mechanism to disable preemption while holding locks or at other 
resources that need to be freed before another task is run?

By the way, are there any other 'modes of execution' for lack of a better 
word, besides IRS, B, and.... 'called from user space', also for lack of a 
better word.  Forgive me, I'm not that familiar with the Linux kernel yet.  

On Thursday 06 September 2001 10:02 pm, Robert Love wrote:
> Available at (about 29K):
>
> http://tech9.net/rml/linux/patch-rml-2.4.10-pre4-preempt-kernel-1
> http://tech9.net/rml/linux/patch-rml-2.4.9-ac9-preempt-kernel-1
>
> for kernel 2.4.10-pre4 and 2.4.9-ac9, respectively.
>
> Changes since previous post:
> * update for new kernels
> * fix newline/space format buglet
>
> Changes since original patch:
> * fix compile bug -- CONFIG_HAVE_DEC_LOCK is set as needed, now.
>
> This patch allows a new config setting, CONFIG_PREEMPT (set in
> `Processor Type and Features') that enables a fully preemptible kernel.
> Preemption is controled via SMP lock points.  Control of execution is
> yielded to higher processes even if the currently running process is in
> kernel space.
>
> This should increase response and decrease latency, and is a highly
> recommended patch for real-time, audio, and embedded systems.  However,
> it is recommended for anyone.  I use it on my everyday workstation.
>
> An interesting new article on a preemptible kernel in linux is available
> at:
>
> http://www.linuxdevices.com/articles/AT5152980814.html

-- 
--> Phill Susi

  reply	other threads:[~2001-09-07  0:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-06 22:02 Robert Love
2001-09-06 20:39 ` Phillip Susi [this message]
2001-09-07  1:10   ` Daniel Phillips
2001-09-07  0:58 ` Robert Love
2001-09-09  4:44 ` Robert Love
2001-09-09 22:38 Robert Love
2001-09-19  0:10 Robert Love
2001-09-19  7:18 ` Robert Love
2001-10-01  4:21 Robert Love
2001-10-01  5:34 ` Steve Kieu
2001-10-01  5:46   ` Robert Love

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=200109070046.f870kEM06465@smtp-server2.tampabay.rr.com \
    --to=psusi@cfl.rr.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rml@tech9.net \
    /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

Powered by JetHome