Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 20 Feb 2002 11:10:53 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        eberkut <eberkut@minithins.net>
Cc:        hackers@freebsd.org
Subject:   Re: Task activation delays: FreeBSD versus Linux?
Message-ID:  <3C73F4BD.51C1C23C@mindspring.com>
References:  <200202201051.g1KApOu346887@logs-wc.proxy.aol.com>

next in thread | previous in thread | raw e-mail | index | archive | help
eberkut wrote:
> No, the andrew morton's low latency patch (and the robert
> love's preempt patch) try to make the kernel himself
> preemptible to reduce latency. There is two different
> approaches :


Uh, neither one of these is Ingo Molnar.  8-).

> 
> "Robert Love: The model we use is to allow the kernel to be
> preempted at any time when it is not locked.  Under this
> design, when an event occurs that causes a higher priority
> task to become runnable, the system will preempt the current
> task and run the higher priority task."
> 
> http://kerneltrap.org/node.php?id=1
> http://www.tech9.net/rml/linux/

Supposedly, JMB's P4 code does this.


> "Andrew Morton: The approach taken by these patches is
> basically cooperative multitasking. The developer identifies
> sections of long-running kernel code and changes them so that
> they will yield the CPU to another task if the scheduler says
> that it's time to do that. Most of the complexity here is in
> being able to back out of any locking before yielding, and in
> cleanly reacquiring locking state when the interrupted task
> resumes."
> 
> http://kerneltrap.org/node.php?id=10
> http://www.zip.com.au/~akpm/linux/schedlat.html


This is the approach we took in NetWare 4.x.  It's inherently
non-SMP scalable, since it makes the assumption that once a
resource is obtained, the act of obtaining the resource blocks
other threads from obtaining it; obviously, resources can not
be held across a yield, unless they are locked.

The way NetWare "scales" for SMP is by running multiple NLM
instances, one per CPU, to make up for this deficiency.


> So I think that the final question is : Is the FreeBSD kernel
> preemptible ? Does he compete on latency ? Is it yet another
> gruik hack from linux ? ;)

Preemptible: yes, if you run a developement kernel (i.e.
Linux is doing the same thing FreeBSD has been doing here).

Compete on latency: it depends on what you mean.  FreeBSD
has fast interrupt handlers, which are different from
standard interrupt handlers, and it has delayed thread
creation, until absolutely necessary (sometimes it's not
necessary at all), so threading context switch overhead in
FreeBSD is significantly lower than that of Linux.  It's
also on track for implicit CPU affinity and thread group
affinity, which means that it should end up having
significantly less scheduler overhead than Linux (more like
Dynix or IRIX).

I think at this point, you are comparing apples and oranges.

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C73F4BD.51C1C23C>