All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Love <rml@tech9.net>
To: Bob McElrath <mcelrath+linux@draal.physics.wisc.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: low-latency patches
Date: 06 Oct 2001 18:36:49 -0400	[thread overview]
Message-ID: <1002407812.1915.21.camel@phantasy> (raw)
In-Reply-To: <20011006010519.A749@draal.physics.wisc.edu>
In-Reply-To: <20011006010519.A749@draal.physics.wisc.edu>

On Sat, 2001-10-06 at 02:05, Bob McElrath wrote:
> [...]
> Correct me if I'm wrong, but the former uses spinlocks to know when it can
> preempt the kernel, and the latter just tries to reduce latency by adding
> (un)conditional_schedule and placing it at key places in the kernel?

Correct.  The low-latency patch does some other work to try to break up
huge routines, too.
 
> My questions are:
> 1) Which of these two projects has better latency performance?  Has anyone
>     benchmarked them against each other?

I suspect you will find a lower average latency with the preemption
patch.  However, I suspect with the low-latency patch you may see a
lower maximum since it works on some of the terribly long-held lock
situations.

In truth, a combination of the two could prove useful.  I have been
working on finding the worst-case non-preemption regions (longest held
lock regions) in the kernel.

> 2) Will either of these ever be merged into Linus' kernel (2.5?)

I hope :)

> 3) Is there a possibility that either of these will make it to non-x86
>     platforms?  (for me: alpha)  The second patch looks like it would
>     straightforwardly work on any arch, but the config.in for it is only in
>     arch/i386.  Robert Love's patches would need some arch-specific asm...

Andrew's patch should work fine on all platforms, although I think the
configure statement is in the processor section so you will need to move
it to arch/alpha/config.in

The preemption patch has a small amount of arch-independent code but we
are working on supporting all architectures.  2.5...


	Robert Love


  parent reply	other threads:[~2001-10-06 22:36 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-06  6:05 low-latency patches Bob McElrath
2001-10-06  6:46 ` Andrew Morton
2001-10-06 16:33   ` Daniel Phillips
2001-10-06 20:42   ` Bob McElrath
2001-10-06 22:00   ` Mike Fedyk
2001-10-06 22:22     ` Robert Love
2001-10-08 12:47     ` Helge Hafting
2001-10-08 17:41       ` george anzinger
2001-10-08 18:24         ` Andrew Morton
2001-10-08 18:36           ` Alan Cox
2001-10-07  1:12   ` Robert Love
2001-10-07  2:38     ` Jeffrey W. Baker
2001-10-07  2:55       ` Robert Love
2001-10-06 22:36 ` Robert Love [this message]
2001-10-06 22:46   ` Mike Fedyk
  -- strict thread matches above, loose matches on Subject: below --
2001-10-10 15:27 David Balazic
2001-03-08 13:06 Andrew Morton

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=1002407812.1915.21.camel@phantasy \
    --to=rml@tech9.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcelrath+linux@draal.physics.wisc.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.