Re: FW: Filesystem gets a huge performance boost
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 changed later. I think that Matt is saying, why bother? Task switches are expensive. With a heavily loaded system, the amount of time spent arbitrating mutexes would exceed spin time. With a lightly loaded system, do we really care that much about spinning? Once the mutexes are in place the underlying implementation can change pretty easily from task switching always to only task switching when the mutex is owned by the same CPU that I'm running I'm not sure that I follow... if the task switch is on the same CPU, then why do we need any new structures? Without a global memory cache*, I think that keeping processes on the same CPU is the first goal, anyway, and increased concurrency second. * Does Intel have any sort of cache coherency mechanism, where a processor can tell other CPUs, "hey, this line is dirty" and the others retrieve the new info as needed? The Alpha? on. (to avoid spinlock deadlock) I agree that task switching _might_ be a performance hit, however that can be fixed by only task switching when in interrupt context. Ughh. AFAIK, traditional wisdom holds that interrupt loops should be as short as possible. Assuming that one performs quick operations, DMA transfers, etc., preemptive task switching *would* be expensive. A lot of things remain to be seen, but only if people like you sit down and start working with the SMP team to achieve the main goal, which is making the kernel MP safe for concurrant execution by locking down the appropriate structures and code paths. Let's look at userland code. I don't use async I/O because I don't want to screw with interrupts and callbacks. Polling of large structures? Ughh. Kernel queues are the solution, and what totally sold me on FreeBSD. How about basing things on *cooperative* multitasking? All else being equal, cooperative is faster because of lower overhead. What makes co-op break down is greedy programs that monopolize the CPU... but there should not be any code like that in the kernel. 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. However, perhaps that could be improved upon: Use something a la kqueue for portions of the kernel to say "I'm waiting for condition XYZ". When we wakeup_one(), we specify "for condition XYZ". We could then avoid waking processes that would only go back to sleep again. I hope that I'm not too far out of my league, here... :-) Eddy --- Brotsman Dreger, Inc. EverQuick Internet / EternalCommerce Division Phone: (316) 794-8922 --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FW: Filesystem gets a huge performance boost
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 meant asleep(). Eddy --- Brotsman Dreger, Inc. EverQuick Internet / EternalCommerce Division Phone: (316) 794-8922 --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel preemption, yes or no? (was: Filesystem gets a hugeperformance boost)
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 idle? In this particular case, let's say that we decide that we have to set ipending and iret immediately, because we're already holding a potential lock when we got interrupted. Isn't the result that we have a second CPU idling while we just set ipending? (I could be missing something, really). (Thinking hard... this is fun stuff...) Also, some mainline interrupt code may need to acquire a really large number of locks, but only in some cases. Let's say we have to first check if we have a free cached buffer sitting somewhere, and if not, malloc() a new one. Well, the malloc() will eventually trigger a chain of mutex lock operations, but only in the case where we lack the cached buffer to allocate it. There is no practical way of telling up front whether or not we'll have to malloc(), so I'm wondering how efficiently we would be able to predict in cases such as these? In this case, why not have a memory allocator similar to Hoard? Let's say that I have a four-way system with 256 MB. First CPU gets first 64 MB, second gets the next 64 MB, and so on. Now we needn't lock before malloc(), because each CPU knows ahead of time what is "off limits". When one reaches a high water mark, it steals half the available space from the CPU with the least memory utilization. This _would_ require a lock, but should only happen in rare instances. I know that memory could become fragmented over time, but as long as we don't screw up caching (which shouldn't be a problem considering that pages are much larger than cache lines), who cares? Eddy --- Brotsman Dreger, Inc. EverQuick Internet / EternalCommerce Division Phone: (316) 794-8922 --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel preemption, yes or no? (was: Filesystem gets a hugeperformance boost)
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 their scheme. IIRC, didn't the NT driver for some NIC (Intel?) switch to polling, anyway, under heavy load? The reasoning being that you _know_ that you're going to get something... why bother an IRQ hit? That said, IRQ distribution sounds like a good thing for the general case. If you have one NIC then obviously you can't take multiple interrupts for that one NIC on different cpu's. No great loss, you generally don't want to do that anyway. Actually, I should think that one would _want_ to serialize traffic for a given NIC. (I'm ignoring when one trunks NICs... speaking of which, anyone have info on 802.3ad? ;-) Otherwise, one ends up with a race that [potentially] screws up packet sequence. Eddy --- Brotsman Dreger, Inc. EverQuick Internet / EternalCommerce Division Phone: (316) 794-8922 --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel preemption, yes or no? (was: Filesystem gets a hugeperformance boost)
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... *ducking and running* Sorry... couldn't resist. :-) Eddy --- Brotsman Dreger, Inc. EverQuick Internet / EternalCommerce Division Phone: (316) 794-8922 --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel preemption, yes or no? (was: Filesystem gets a hugeperformance boost)
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 tight loop, task switching becomes expensive. peek at the card when you have time. Think aio_ versus kernel queues. :-) This means pure interrupts can possibly DoS a CPU (think about a gigabit ping flood) while polling leaves the box alive and still allows it to process as much as it can (while not wasting CPU on taking in packets it cannot process higher up the stack). I should hope that the card would be smart enough to combine consecutive packets into a single DMA transfer, but I know what you mean. Eddy --- Brotsman Dreger, Inc. EverQuick Internet / EternalCommerce Division Phone: (316) 794-8922 --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel preemption, yes or no? (was: Filesystem gets a hugeperformance boost)
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 extreme: Create a Transputer-like array with hundreds of 65xx-complexity CPUs. Each atomic task runs on its own private CPU. The problem is that the electronics become a pain, and are often idle. When too many tasks are launched, we run out of CPU power. The compromise is to switch tasks on whatever CPU power is available... balancing switching overhead with latency. *Let the latency be as high as is acceptable to reduce overhead as low as is practical.* 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 best thing to straight run-to-completion. Eddy --- Brotsman Dreger, Inc. EverQuick Internet / EternalCommerce Division Phone: (316) 794-8922 --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel preemption, yes or no? (was: Filesystem gets a hugeperformance boost)
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 best thing to straight run-to-completion. Except that for the [extremely performance critical] interrupt handlers the "software" is under control of the folks who write the OS. You need preemption for userspace because it's possibly "hostile" software, but things like the interrupt handlers and the kernel code are under your control ... this means you can code it to be as efficient as possible without impacting latency too much. Right. This is why I think that messing with pre-emption inside interrupt handlers is a bad thing. If kernel code doesn't cooperatively time-share, then we likely have bigger problems than task switching. :-) Hence I'm curious about replacing Giant with a token-passing mechanism. If the token equals your CPU number, you have "Giant"... do what's needed. Then set the token to the next CPU, and do what doesn't require "Giant". Matt pointed out (to me off-list IIRC) that the mutex usually shouldn't have to spin. However, passing a token would involve changing the value of some known memory location... that should be even faster and simpler than a mutex. No bus locking, no spinning... AFAIK, there isn't any "good" support specifically for token passing. But memory reads and writes that don't even require the lock prefix... how much faster and simpler can you get? Want finer-grained control than "Giant"? Any time you have "Giant"/token, you can poll (and claim, if available) any more-specific mutex. Nobody else has G/tk, so there would be no races. By using fine-grained co-op mutexes, there is very little that must be done when we have G/tk, thus minimizing wait for G/tk. Note, too, that we run our standard scheduler when we don't yet have G/tk, so we're not even blocking unless the CPU is totally idle... and then, the degenerate case is spinning. Eddy --- Brotsman Dreger, Inc. EverQuick Internet / EternalCommerce Division Phone: (316) 794-8922 --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-current destabilization
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 --- Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to [EMAIL PROTECTED], or you are likely to be blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Unfortunate dynamic linking for everything
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 update all of the static binaries that might use them. Although this doesn't help the upgrade process, what if one symbol (such as function name + CVS tag) were exported per function? One could check for a vulnerability by strings | grep funcname | inspect CVS tag. A more elegant approach would be to store such versioning in another segment and have a tool that understands the data, a la debugger symbols. On a different note: + Some of us have had a few bad experiences with glibc (granted, it's glibc) upgrades when the shell, cp, ls, et cetera are dynamically linked. + I put the shell of choice and all of SSH's guts on the root partition... if /usr gets clobbered, I still want to be able to boot and log in remotely. If / gets clobbered, I have bigger problems. :-) Eddy -- Brotsman Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _ DO NOT send mail to the following addresses : [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unfortunate dynamic linking for everything
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 upgrades. Everyone would want GAD the security updates, even if they're on a slow link. When security updates change but a few bytes, it seems that some xdiff- or rsync-like algorithm would be an apropriate way to distribute patches. Eddy -- Brotsman Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _ DO NOT send mail to the following addresses : [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
rtld + static linking
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 program couldn't include some ld-elf.a type of intelligence? Would that be necessary and sufficient to allow statically-linked programs to load shared objects? Eddy -- Brotsman Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _ DO NOT send mail to the following addresses : [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
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 involved... which received no responses. I assume that not much has changed since the mid- to late-90s list archives I found via Google... What specific aspects of rtld are required to support NSS in static binaries? dlopen(), fixups, and dlsym()? Eddy -- Brotsman Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _ DO NOT send mail to the following addresses : [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
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 rate to prevent dictionary attacks? Sounds kind of like SASL... Eddy -- Brotsman Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _ DO NOT send mail to the following addresses : [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Apples linking
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 than adding special-purpose system calls RW that complicated various code paths, and that aren't RW portable. Would rtld-elf/rtld.c:map_object() be a reasonable place to add hooks for speaking with a daemon that does the actual tracking work? True, the daemon might die... in which case rtld probably should revert to traditional behavior rather than refusing to load a binary. Eddy -- Brotsman Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _ DO NOT send mail to the following addresses : [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
