Re: HELP!!! -CURRENT libtool problem.
You're correct in that better awareness is almost definitely the key. Would you consider posting the -stable and -current port build results You can find the realtime results from http://bento.freebsd.org/ -- -- David([EMAIL PROTECTED] -or- [EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Thread stack allocation (was Re: cvs commit: src/lib/libc_r Makefile src/lib/libc_r/uthread pthread_private.h uthread_create.c uthread_gc.c uthread_init.c)
On Mon, Jul 12, 1999 at 10:53:49PM +0400, Dmitrij Tejblum wrote: I don't see how MAP_ANON is better than MAP_STACK. It consumes fewer resources. Each time you grow the stack, it adds another vm_map_entry to the vm_map and (eventually) allocates another vm_object. Using MAP_ANON, there is at most one vm_object and one vm_map_entry (until an mprotect chops it up). ... Anyway, what are the advantages of mmap over malloc? Especially if you change MAP_STACK to MAP_ANON? None really. But, the real point (as I've explained on the -committers list) is that there's no reason to use MAP_STACK in a FreeBSD-native program. Alan P.S. As an aside, just once, everyone should look at the /proc/"pid"/map of a running cvsup. Each line you see is a vm_map_entry. (What you see is a result of Modula-3's garbage collector.) Roughly speaking, on a page fault, if we're not faulting on the same range of addresses as the last page fault, a linear cost search is performed to find the correct entry. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: objtrm problem probably found (was Re: Stuck in objtrm)
Before this thread on "cache coherence" and "memory consistency" goes any further, I'd like to suggest a time-out to read something like http://www-ece.rice.edu/~sarita/Publications/models_tutorial.ps. A lot of what I'm reading has a grain of truth but isn't quite right. This paper appeared as a tutorial in IEEE Computer a couple years ago, and is fairly accessible to a general audience. Alan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Using float emulator on a system with FPU?
As Poul-Henning Kamp wrote ... In message [EMAIL PROTECTED], "Bria I suggested about half a year ago that we should officially desupport non-FPU configurations in 4.0. Unfortunately, my resolution was soundly defeated. Why shouldn't we? Noone uses machines without FPUs anymore. What non-ancient CPU doesn't have an FPU? And we're talking about the i386 family here... A lot of 386 machines are being built into places where people will never know they are. We should not kill that market. www.tcja.nl was an ancient 386/40 until a couple of months ago. Low traffic Web servers don't (generally) need an FPU. No/low budget outfits run hardware most people on this list would give away for free (or thrash altogether). It is a M$-ism to discard a complete line of machines with each next release... Just my Dfl 0.02 -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Using float emulator on a system with FPU?
Wilko Bulte wrote in list.freebsd-current: As Poul-Henning Kamp wrote ... In message [EMAIL PROTECTED], "Bria I suggested about half a year ago that we should officially desupport non-FPU configurations in 4.0. Unfortunately, my resolution was soundly defeated. Why shouldn't we? Noone uses machines without FPUs anymore. What non-ancient CPU doesn't have an FPU? And we're talking about the i386 family here... A lot of 386 machines are being built into places where people will never know they are. We should not kill that market. www.tcja.nl was an ancient 386/40 until a couple of months ago. Low traffic Web servers don't (generally) need an FPU. No/low budget outfits run hardware most people on this list would give away for free (or thrash altogether). It is a M$-ism to discard a complete line of machines with each next release... I agree 100%. My "mobile emergency terminal" is an old 486SX notebook with 3.5 Mbyte RAM and 120 Mbyte HD. It works perfectly well for what I use it for. And I'd hate to have to keep an "old" release around for it while upgrading all other boxes. (Remember, 486SX processors don't have FPUs either.) Regards Oliver PS: No, I'm not doing "make world" on it. (In fact, I removed the compiler toolchain to save HD space.) -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: objtrm problem probably found (was Re: Stuck in objtrm)
On Mon, Jul 12, 1999 at 10:38:03PM -0700, Mike Smith wrote:
I said:
than indirect function calls on some architectures: inline
branched code. So you still have a global variable selecting
locked/non-locked, but it's a boolean, rather than a pointer.
Your atomic macros are then { if (atomic_lock) asm("lock;foo");
else asm ("foo"); }
This requires you to have all the methods present at compile time,
which defeats the entire purpose of dynamic method loading.
Pardon? I didn't see a discussion of dynamic loading anywhere
here. We were referring to tiny inlined assembly language routines.
The existing implementation is #defines in a C header file.
Uh, no, I was asking about the overhead involved in indirect function
calls specifically because there are instances where fast indirect
methods would allow us to greatly improve the generality of parts of
the FreeBSD kernel and modules. This includes code where we are
currently using compile-time defines that require us to trade
performance for generality.
--
\\ The mind's the standard \\ Mike Smith
\\ of the man. \\ [EMAIL PROTECTED]
\\-- Joseph Merrick \\ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: LOCK overheads (was Re: objtrm problem probably found)
According to Matthew Dillon: Wow, now that *is* expensive! The K6 must be implementing it in microcode for it to be that bad. K6-200: 244 [21:57] roberto@keltia:src/C ./locktest 0 ... empty 26.84 ns/loop 1proc 22.62 ns/loop 2proc 22.64 ns/loop empty w/locks 17.58 ns/loop 1proc w/locks 288.28 ns/loop 2proc w/locks 288.16 ns/loop It hurts :( -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #72: Mon Jul 12 08:26:43 CEST 1999 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: LOCK overheads (was Re: objtrm problem probably found)
Matthew Dillon [EMAIL PROTECTED] wrote: :mode 1 17.99 ns/loop nproc=1 lcks=no :mode 3 166.33 ns/loop nproc=1 lcks=yes ... :This is a K6-2 350. Locks are pretty expensive on them. Wow, now that *is* expensive! The K6 must be implementing it in microcode for it to be that bad. I wouldn't be surprised if lock prefixes did result in microcode execution. As I stated yesterday, I don't believe locked instructions are implemented frequently enough to warrant special handling, and are therefore likely to be implemented in whichever way need the least chip area. Since you need to be able to track and mark the memory references associated with the instruction, the cheapest implementation (in terms of dedicated chip area) is likely to be something like: wait until all currently executing instructions are complete, wait until all pending memory writes are complete (at least to L1 cache), assert the lock pin and execute RMW instuction without allowing any other instructions to commence, deassert lock pin. This is (of course) probably the worst case as far as execution time as seen by that CPU - though it's not far off optimal as seen by other CPUs. (`Assert lock pin' should also be mapped into a `begin locked memory reference' using whatever cache coherency protocol is being used). I'm not saying that you can't implement a locked RMW sequence a lot better, but until the chip architects decide that the performance is an issue, they aren't likely to spend any silicon on it. The big IA-32 market is UP systems running games - and locked RMW instructions don't affect this market. Intel see the high-end of the market (where SMP and hence locked RMW is more of an issue) moving to Merced. This suggests that it's unlikely that the IA-32 will ever acquire a decent lock capability (though at least the PIII is no worse than the PII). That said, the above timings make a lock prefix cost over 50 core clocks (or 15 bus clocks) - even microcode couldn't be that bad. My other timings (core/bus cycles) were: 486DX2: 20/10, Pentium: 28/7, P-II: 34/8.5, P-III 34/7.5. I suspect that these timings are a combination of inefficient on-chip implementation of the lock prefix (see above for my reasoning behind this), together with poor off-chip handling of locked cycles. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: When will -CURRENT support PCMCIA modems again?
In message [EMAIL PROTECTED] Greg Lehey writes: : I've just updated my laptop from 3.2-RELEASE to 4.0-CURRENT, and I : find that PCMCIA modems (sio) are no longer supported. I'm playing : around with it to get it to work, but so far I've just managed to get : panics out of sioprobe. Before I continue with this: is anybody else : working on it? If so, I'll get out of your way. I think I have an idea on how to make this work, but have not had the time to make it work. I've taken the day off (mostly because my brother was in town through today) and am trying to get my system working again with the current pccard code Once that happens, it should be a couple hours to maybe having an interesting kludge to make new-bus drivers have pccard attachments if I'm lucky... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic in -current (trap 12)
This is with a current kernel - a kernel built 2 days ago runs ok. The system crashes at boot, just after the disk checks. I don't have a core dump, only the message printed on screen: fault code: supervisor read , page not present instruction pointer: 0xc0175396 from my kernel: c0175234 t vfs_setdirty c0175360 T getblk c01756f8 T geteblk c017573c T allocbuf This is on a SMP/softupdates system. Jean-Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
