Re: FW: Filesystem gets a huge performance boost

2001-04-17 Thread E.B. Dreger
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 possibly

Re: FW: Filesystem gets a huge performance boost

2001-04-17 Thread E.B. Dreger
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 trying to screw with mutexes. Oops. I

Re: Kernel preemption, yes or no? (was: Filesystem gets a hugeperformance boost)

2001-04-17 Thread E.B. Dreger
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 becomes

Re: Kernel preemption, yes or no? (was: Filesystem gets a hugeperformance boost)

2001-04-17 Thread E.B. Dreger
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 in

Re: Kernel preemption, yes or no? (was: Filesystem gets a hugeperformance boost)

2001-04-17 Thread E.B. Dreger
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 buffer...

Re: Kernel preemption, yes or no? (was: Filesystem gets a hugeperformance boost)

2001-04-17 Thread E.B. Dreger
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 a

Re: Kernel preemption, yes or no? (was: Filesystem gets a hugeperformance boost)

2001-04-17 Thread E.B. Dreger
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

Re: Kernel preemption, yes or no? (was: Filesystem gets a hugeperformance boost)

2001-04-18 Thread E.B. Dreger
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 the next

-current destabilization

2001-06-29 Thread E.B. Dreger
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

Re: Unfortunate dynamic linking for everything

2003-11-19 Thread E.B. Dreger
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 to SL

Re: Unfortunate dynamic linking for everything

2003-11-19 Thread E.B. Dreger
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

rtld + static linking

2003-11-23 Thread E.B. Dreger
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

Re: 40% slowdown with dynamic /bin/sh

2003-11-24 Thread E.B. Dreger
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

Re: 40% slowdown with dynamic /bin/sh

2003-11-26 Thread E.B. Dreger
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 challenge MD

Re: Apples linking

2003-11-27 Thread E.B. Dreger
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, rather