> Date: Tue, 17 Apr 2001 14:52:06 -0700
> From: Alfred Perlstein <[EMAIL PROTECTED]>
Disclaimer: I am not a kernel hacker.
> The goal is to have a kernel that's able to have more concurrancy,
Right...
> things like pre-emption and task switching on mutex collisions can
> be examined and possib
> Date: Tue, 17 Apr 2001 15:00:29 -0700 (PDT)
> From: Matt Dillon <[EMAIL PROTECTED]>
>
> WILL be a performance hit. WILL introduce major bugs. IS unnecessary,
> DOESN'T make any sense whatsoever, is at CROSS PURPOSES with goals
> already stated (not having any serious contention in the first p
> Date: Tue, 17 Apr 2001 22:18:34 + (GMT)
> From: E.B. Dreger <[EMAIL PROTECTED]>
>
> My instinct (whatever it's worth; remember my disclaimer) is that co-op
> switching using something like tsleep() and wakeup_one() or similar would
> be more efficient than
(cross-posting to SMP and renaming in an effort to move the thread)
> Date: Tue, 17 Apr 2001 16:04:18 -0700
> From: Alfred Perlstein <[EMAIL PROTECTED]>
(Repeat disclaimer: I am not a kernel hacker.)
> seriously, it would be _trivial_ to:
>
> 1) make interrupts the only thing that could swit
> Date: Tue, 17 Apr 2001 21:20:45 -0400
> From: Bosko Milekic <[EMAIL PROTECTED]>
>
> What happens if we get an interrupt, we're thinking about servicing
> it, about to check whether we're already holding a mutex that may
> potentially be used inside the mainline int routine, and another CPU
> be
> Date: Tue, 17 Apr 2001 18:28:40 -0700
> From: Alfred Perlstein <[EMAIL PROTECTED]>
>
> 1) interrupts are again fan-in, meaning if you block an interrupt
> class on one cpu you block them on all cpus
When would this be a bad case? i.e., if an interrupt [class] must be
blocked, would we
> Date: Tue, 17 Apr 2001 19:06:08 -0700 (PDT)
> From: Matt Dillon <[EMAIL PROTECTED]>
>
> They don't have to be. If you have four NICs each one can be its own
> interrupt, each with its own mutex. Thus all four can be taken in
> parallel. I was under the impression that BSDI had achieved that
> Date: Tue, 17 Apr 2001 19:34:56 -0700 (PDT)
> From: Matt Dillon <[EMAIL PROTECTED]>
>
> Yes. Also NICs usually have circular buffers for packets so, really,
> only one cpu can be processing a particular NIC's packets at any given
> moment.
We could always have a mutex for each NIC's ring buff
> Date: Wed, 18 Apr 2001 00:04:12 -0300 (BRST)
> From: Rik van Riel <[EMAIL PROTECTED]>
>
> Not true. Interrupts work worse than polling because the interrupt
> top halves can keep the CPU busy, whereas with polling you only
Top halves and _task switching_. Again, in a well-written handler with
Going back to basic principles:
For minimal CPU utilization, it would be nice skip task switching, period.
Run something to completion, then go on to the next task. Poll without
ever using an interrupt.
The problem is that latency becomes totally unacceptable.
So now let's go to the other extr
> Date: Wed, 18 Apr 2001 01:38:14 -0300 (BRST)
> From: Rik van Riel <[EMAIL PROTECTED]>
>
> > Hence, my philosophy is that task switching and preemption are
> > necessary evils because hardware does not perfectly accomodate
> > software. If we must, we must... otherwise, use co-op switching as
>
Any best guesses when -current will be destabilized for the SMPng
hackathon?
Eddy
---
Brotsman & Dreger, Inc.
EverQuick Internet Division
Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence
SL> Date: Tue, 18 Nov 2003 17:06:06 -0700 (MST)
SL> From: Scott Long
SL> 3. Binary security updates: there is a lot of interest in providing a
SL> binary update mechanism for doing security updates. Having a dynamic
SL> root means that vulnerable libraries can be updated without having t
GAD> Date: Tue, 18 Nov 2003 21:54:53 -0500
GAD> From: Garance A Drosihn
GAD> Many freebsd users (me for one) are still living on a modem,
GAD> where even one bump of 1.5 meg is a significant issue...
GAD>
GAD> Remember that the issue we're talking about is security
GAD> updates, not full system u
After watching the recent shared/dynamic threads, and reading the
archives from five or six years ago, I have a question...
Dynamic linking works by the kernel running the dynamic linker,
which loads shared objects and fixes the symbol tables, yes? Is
there some reason that a statically-linked pr
PW> Date: Mon, 24 Nov 2003 18:56:21 -0800
PW> From: Peter Wemm
PW> We need nsswitch type functionality in /bin/sh. To the
PW> people who want to make it static, lets see some static
PW> binary dlopen() support or a nsswitch proxy system.
I started a new thread inquiring about the challenges invo
MD> Date: Tue, 25 Nov 2003 11:50:25 -0800 (PST)
MD> From: Matthew Dillon
MD> (B) the authentication code access an IPC service which *ONLY* allows
MD> challenge/response, does *NOT* give you direct access to the
MD> encrypted contents of the password file, and which limits the challeng
RW> Date: Thu, 27 Nov 2003 11:24:23 -0500 (EST)
RW> From: Robert Watson
[ CC list trimmed ]
RW> The one thing that turns me off to this scheme is that I'd
RW> like it if we could find a way to represent this using solely
RW> existing BSD/UNIX kernel primitives (mmap, et al) and
RW> userspace, ra
18 matches
Mail list logo
