Re: more -current testers
Hello, These proposed articles can only help. I've been following this list for a few years, I'm ready to contribute in my own small way :-) tom [EMAIL PROTECTED] Michael Lucas wrote: I understand that we're getting to that stage where we need more -current testers. We all agree that the optimal thing would be to have hordes of very sophisticated users who can debug problems on their own and submit patches to fix all their issues. I would guess that we all also agree that that's not going to happen. It seems that the best we can hope for is to educate some of the braver users who are ready to take the next step and are willing to donate some time to us. I'm considering doing a series of articles on testing FreeBSD-current, including: setting up for kernel dumps, what to type at the debugger prompt after a crash, filing a decent bug report, what to expect from -current, and so on. I would also make it clear when to not bother filing a bug report (i.e., You crashed, but had no WITNESS? Sorry, enable WITNESS try again.). This would be (I suspect) three articles, running about a month and a half. The last time I checked, I get 12-15 thousand readers for each article. One half of one percent uptake would (hopefully) be quite a few bug reports. My question to the community is: is it too early to do this? If I start now, the articles would probably appear April-May. Thanks, Michael To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: more -current testers
Michael Lucas wrote: I understand that we're getting to that stage where we need more -current testers. We all agree that the optimal thing would be to have hordes of very sophisticated users who can debug problems on their own and submit patches to fix all their issues. I would guess that we all also agree that that's not going to happen. It seems that the best we can hope for is to educate some of the braver users who are ready to take the next step and are willing to donate some time to us. I'm considering doing a series of articles on testing FreeBSD-current, including: setting up for kernel dumps, what to type at the debugger prompt after a crash, filing a decent bug report, what to expect from -current, and so on. I would also make it clear when to not bother filing a bug report (i.e., You crashed, but had no WITNESS? Sorry, enable WITNESS try again.). This would be (I suspect) three articles, running about a month and a half. The last time I checked, I get 12-15 thousand readers for each article. One half of one percent uptake would (hopefully) be quite a few bug reports. Excellent idea IMO. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: mergemaster and /etc/pam.d
On Fri, 4 Jan 2002, John Baldwin wrote: On 04-Jan-02 Michael D. Harnois wrote: mergemaster does not pick up changes to the /etc/pam.d directory. Is this a feature? I don't think pam.d is installed right now by default. Once it is turned on by default I think mergemaster will DTRT. John's right. By design, mm only knows about things installed by /usr/src/etc/Makefile. That makes it flexible over time and much easier to keep up to date. Doug -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mergemaster and /etc/pam.d
Doug Barton [EMAIL PROTECTED] writes: On Fri, 4 Jan 2002, John Baldwin wrote: I don't think pam.d is installed right now by default. Once it is turned on by default I think mergemaster will DTRT. John's right. By design, mm only knows about things installed by /usr/src/etc/Makefile. That makes it flexible over time and much easier to keep up to date. pam.d *is* listed in etc/Makefile, and mergemaster *does* pick up changes to it, as long as the RCS Id changed. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel compile error with today's cvsup.
On my daily build, my kernels are broken as per log: === wi cd /usr/obj/usr/src/sys/PIII850N; MAKESRCPATH=/usr/src/sys/dev/aic7xxx/aicasm make - f /usr/src/sys/dev/aic7xxx/aicasm/Makefile Warning: Object directory not changed from original /usr/obj/usr/src/sys/PIII850N cc -O -pipe -I/usr/include -I.-c aicasm_gram.c cc: installation problem, cannot exec `cpp0': No such file or directory cc: installation problem, cannot exec `cc1': No such file or directory *** Error code 1 Thanks, ed --- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Panic with today's -CURRENT at runq_choose+0x83
Just built installed today's -CURRENT (CVSup around 0347 hrs. PST): Wed Feb 20 05:48:23 PST 2002 FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0) login: Fboot() called on cpu#0 Waiting (max 60 seconds) for system process `vnlru' to stop...stopped lock order reversal 1st 0xc0337420 sched lock @ /usr/src/sys/kern/kern_idle.c:105 2nd 0xc0390840 sio @ /usr/src/sys/dev/sio/sio.c:3137 kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = fault virtual address = 0xd6820001 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01a78cf stack pointer = 0x10:0xd683ccd0 frame pointer = 0x10:0xd683cce0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 11 (idle: cpu0) kernel: type 12 trap, code=0 timeout stopping cpus Stopped at runq_choose+0x83: movl0(%edx),%eax db trace runq_choose(c035a660,d683cd0c,c02b1b3e,c01a8d87,12e) at runq_choose+0x83 choosethread(c01a8d87,12e,c0196384,d682c500,1a09) at choosethread+0xd sw1(d682c600,d683cd34,c01961c4,0,d683cd48) at sw1+0x20 idle_proc(0,d683cd48,0,c0196384,0) at idle_proc+0x5c fork_exit(c0196384,0,d683cd48) at fork_exit+0x9c fork_trampoline() at fork_trampoline+0x8 db show pcpu 0 cpuid= 0 curthread= 0xd682c600: pid 11 idle: cpu0 curpcb = 0xd683cda0 fpcurthread = none idlethread = 0xd682c600: pid 11 idle: cpu0 currentldt = 0x28 spin locks held: exclusive (spin mutex) sched lock (0xc0337420) locked @ /usr/src/sys/kern/kern_idle.c:105 db show pcpu 1 cpuid= 1 curthread= 0xda408700: pid 90879 reboot curpcb = 0xda4b8da0 fpcurthread = none idlethread = 0xd682c900: pid 10 idle: cpu1 currentldt = 0x28 spin locks held: exclusive (spin mutex) clk (0xc033ad00) locked @ /usr/src/sys/i386/isa/clock.c:415 db show locks exclusive (spin mutex) sched lock (0xc0337420) locked @ /usr/src/sys/kern/kern_idle.c:105 db I have some errands to run; should be back within about 1.5 hrs., but will be quite willing to poke hack around to see what's up after that time. Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
cannot exec `cpp0': No such file or directory
Hello, Just made world, and now cc(1) fails: $ cc p.c -o p cc: installation problem, cannot exec `cpp0': No such file or directory Using ktrace(1), I found that now cc searchs its subcomponents in /usr/libexec/elf. However, installworld puts them in /usr/libexec. Nothing is said about this problem in UPDATING. Could this problem be related to the recent changes to src/gnu/usr.bin/cc/cc_tools/freebsd-native.h (1.10, 1.11)? Cheers, JMA -- ** Jose M. Alcaide // [EMAIL PROTECTED] // [EMAIL PROTECTED] ** ** Beware of Programmers who carry screwdrivers -- Leonard Brandwein ** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ethernet tunnel device
* Mark Santcroos [EMAIL PROTECTED] [020220 03:52] wrote: It was indeed a linux_compat specific resource cleanup issue. I managed to create a simple linux program that had the same problem. From there on it was easy... The problem was created by Alfred's locking commit of Jan 13. (No hard feelings, it helped me to understand the code alot better! ;) ) Can someone please commit the attached (trivial) patch? Done. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel compile error with today's cvsup.
On my daily build, my kernels are broken as per log: === wi cd /usr/obj/usr/src/sys/PIII850N; MAKESRCPATH=/usr/src/sys/dev/aic7xxx/aicasm make - f /usr/src/sys/dev/aic7xxx/aicasm/Makefile Warning: Object directory not changed from original /usr/obj/usr/src/sys/PIII850N cc -O -pipe -I/usr/include -I.-c aicasm_gram.c cc: installation problem, cannot exec `cpp0': No such file or directory cc: installation problem, cannot exec `cc1': No such file or directory *** Error code 1 I don't think it is the kernel. My make release failed with the same type of error and that machine's kernel is from Jan 28. Maybe it is the search path that changed in gnu/usr.bin/cc/cc_tools/freebsd-native.h ... Just a guess. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cannot exec `cpp0': No such file or directory
On Wed, Feb 20, 2002 at 06:02:38PM +0100, Jose M. Alcaide wrote: Using ktrace(1), I found that now cc searchs its subcomponents in /usr/libexec/elf. However, installworld puts them in /usr/libexec. ... Could this problem be related to the recent changes to src/gnu/usr.bin/cc/cc_tools/freebsd-native.h (1.10, 1.11)? I need to see the output of ``/usr/bin/cc -print-search-dirs'' from the problematic compiler. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel compile error with today's cvsup.
On Wed, Feb 20, 2002 at 05:53:59AM -0800, Edwin Culp wrote: On my daily build, my kernels are broken as per log: === wi cd /usr/obj/usr/src/sys/PIII850N; MAKESRCPATH=/usr/src/sys/dev/aic7xxx/aicasm make - f /usr/src/sys/dev/aic7xxx/aicasm/Makefile Warning: Object directory not changed from original /usr/obj/usr/src/sys/PIII850N cc -O -pipe -I/usr/include -I.-c aicasm_gram.c cc: installation problem, cannot exec `cpp0': No such file or directory cc: installation problem, cannot exec `cc1': No such file or directory *** Error code 1 I need to see the output of ``/usr/bin/cc -print-search-dirs'' from the problematic compiler. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cannot exec `cpp0': No such file or directory
On Wed, Feb 20, 2002 at 09:21:14AM -0800, David O'Brien wrote: I need to see the output of ``/usr/bin/cc -print-search-dirs'' from the problematic compiler. $ /usr/bin/cc -print-search-dirs install: /usr/libexec/(null) programs: /usr/libexec/elf/ libraries: /usr/lib/ -- ** Jose M. Alcaide // [EMAIL PROTECTED] // [EMAIL PROTECTED] ** ** Beware of Programmers who carry screwdrivers -- Leonard Brandwein ** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Sorry, false alarm (was: Panic with today's -CURRENT at runq_choose+0x83)
Date: Wed, 20 Feb 2002 07:49:19 -0800 (PST) From: David Wolfskill [EMAIL PROTECTED] Just built installed today's -CURRENT (CVSup around 0347 hrs. PST): ... Stopped at runq_choose+0x83: movl0(%edx),%eax db trace runq_choose(c035a660,d683cd0c,c02b1b3e,c01a8d87,12e) at runq_choose+0x83 choosethread(c01a8d87,12e,c0196384,d682c500,1a09) at choosethread+0xd sw1(d682c600,d683cd34,c01961c4,0,d683cd48) at sw1+0x20 idle_proc(0,d683cd48,0,c0196384,0) at idle_proc+0x5c fork_exit(c0196384,0,d683cd48) at fork_exit+0x9c fork_trampoline() at fork_trampoline+0x8 Ahhh... that would seem to have been merely fallout from the upgrade process I used. A subsequent reboot worked fine: freebeast(5.0-C)[1] uname -a FreeBSD freebeast.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #84: Wed Feb 20 07:20:46 PST 2002 [EMAIL PROTECTED]:/common/S4/obj/usr/src/sys/FREEBEAST i386 freebeast(5.0-C)[2] and I didn't even have the above-referenced panic at all on my laptop: g1-7(5.0-C)[1] uname -a FreeBSD g1-7.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #3: Wed Feb 20 09:13:13 PST 2002 [EMAIL PROTECTED]:/common/S3/obj/usr/src/sys/LAPTOP_30W_NC i386 g1-7(5.0-C)[2] So... move along, folks; nothing to see here Sorry for the noise. Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cannot exec `cpp0': No such file or directory
On Wed, Feb 20, 2002 at 06:02:38PM +0100, Jose M. Alcaide wrote: $ cc p.c -o p cc: installation problem, cannot exec `cpp0': No such file or directory Fixed. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ethernet tunnel device
Mark Santcroos wrote: On Sat, Feb 16, 2002 at 01:02:09AM -0800, Terry Lambert wrote: Pretty clearly, if it happens, and the process is truly gone, then there is a resource track cleanup that's missing (perhaps it's a reference that results from the Linux mmap resource track cleanup not releasing it?). It was indeed a linux_compat specific resource cleanup issue. Cool. No zebras. 8-). I managed to create a simple linux program that had the same problem. From there on it was easy... The problem was created by Alfred's locking commit of Jan 13. (No hard feelings, it helped me to understand the code alot better! ;) ) Can someone please commit the attached (trivial) patch? Alfred... that would be for you? 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ethernet tunnel device
* Terry Lambert [EMAIL PROTECTED] [020220 11:13] wrote: Mark Santcroos wrote: I managed to create a simple linux program that had the same problem. From there on it was easy... The problem was created by Alfred's locking commit of Jan 13. (No hard feelings, it helped me to understand the code alot better! ;) ) Can someone please commit the attached (trivial) patch? Alfred... that would be for you? 8-). All patches are trivial, it's the bugs that are a b*tch. Yes, the patch has been committed. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel compile error with today's cvsup.
David, I see it's already fixed so I'll assume that you no longer need the compiler output. I'm sorry that I didn't answer before but I just checked my email and went to some meetings and am just getting back. Thanks for your help, ed Quoting David O'Brien [EMAIL PROTECTED]: On Wed, Feb 20, 2002 at 05:53:59AM -0800, Edwin Culp wrote: On my daily build, my kernels are broken as per log: === wi cd /usr/obj/usr/src/sys/PIII850N; MAKESRCPATH=/usr/src/sys/dev/aic7xxx/aicasm make - f /usr/src/sys/dev/aic7xxx/aicasm/Makefile Warning: Object directory not changed from original /usr/obj/usr/src/sys/PIII850N cc -O -pipe -I/usr/include -I.-c aicasm_gram.c cc: installation problem, cannot exec `cpp0': No such file or directory cc: installation problem, cannot exec `cc1': No such file or directory *** Error code 1 I need to see the output of ``/usr/bin/cc -print-search-dirs'' from the problematic compiler. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt --- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: pgrp/session patch
On 19-Feb-02 Seigo Tanimura wrote: Here is the most up-to-date version of pgrp/session lock (at Change 6700): http://people.FreeBSD.org/~tanimura/patches/pgrp10.diff.gz I would like to commit this on the next Sunday. Otherwise, my patch would conflict with other patches, especially tty. I've looked over other versions of this patch and am happy with them, so I have no objections. :) -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Patch to improve mutex collision performance
On 18-Feb-02 Matthew Dillon wrote:
While testing some Giant removal stuff I noticed that my current
system sometimes got into an extremely non-optimal flip-flop situation
between two processes contesting Giant on an SMP system which halved the
syscall performance in the test.
In my getuid test, for example, with Giant in place I was getting
683Kcalls/sec with one process and 427Kcalls/sec with two. Giant
was being obtained in two places: in userret and in getuid().
When I turned off Giant in getuid() the syscall performance actually
went DOWN, to 250Kcalls/sec with two processes. This was a totally
unexpected result.
It turns out that the two processes got into an extremely non-optimal
contested/sleep/wakeup situation, even though they do not actually have
to sleep on Giant in this situation.
The solution is to allow _mtx_lock_sleep() to spin instead of sleep in
the situation where: (1) there are no runnable processes other then
the ones already running on a cpu, (2) interrupts are enabled, and
(3) the mutex in question is not contested (to avoid starving the thread
contesting the mutex). In this case we can spin.
This will go in tonight if no problems arise.
I would rather make the locks adaptive like so: (untested)
--- //depot/projects/smpng/sys/conf/options 2002/02/08 13:19:07
+++ //depot/user/jhb/lock/conf/options 2002/02/08 13:50:54
@@ -56,6 +56,7 @@
# mapped I/O
# Miscellaneous options.
+ADAPTIVE_MUTEXES
BLEED
COMPAT_43 opt_compat.h
COMPAT_SUNOS opt_compat.h
--- //depot/projects/smpng/sys/i386/include/cpufunc.h 2001/12/18 13:07:32
+++ //depot/user/jhb/lock/i386/include/cpufunc.h2001/12/20 15:54:32
@@ -550,6 +550,12 @@
__asm __volatile(movl %0,%%dr7 : : r (sel));
}
+static __inline void
+cpu_pause(void)
+{
+ __asm __volatile(pause);
+}
+
static __inline critical_t
cpu_critical_enter(void)
{
--- //depot/projects/smpng/sys/kern/kern_mutex.c2002/02/08 14:19:21
+++ //depot/user/jhb/lock/kern/kern_mutex.c 2002/02/08 13:50:54
@@ -34,6 +34,7 @@
* Machine independent bits of mutex implementation.
*/
+#include opt_adaptive_mutexes.h
#include opt_ddb.h
#include sys/param.h
@@ -345,7 +354,22 @@
continue;
}
+#if defined(SMP) defined(ADAPTIVE_MUTEXES)
/*
+* If the current owner of the lock is executing on another
+* CPU, spin instead of blocking.
+*/
+ if (((struct thread *)(v MTX_FLAGMASK)-td_kse-kse_oncpu !=
+ NOCPU) {
+ mtx_unlock_spin(sched_lock);
+#ifdef __i386__
+ cpu_pause();
+#endif
+ continue;
+ }
+#endif /* SMP ADAPTIVE_MUTEXES */
+
+ /*
* We deffinately must sleep for this lock.
*/
mtx_assert(m, MA_NOTOWNED);
@@ -433,6 +457,9 @@
/* Give interrupts a chance while we spin. */
critical_exit();
while (m-mtx_lock != MTX_UNOWNED) {
+#ifdef __i386__
+ cpu_pause();
+#endif
if (i++ 1000)
continue;
if (i++ 6000)
This is more a specific problem with Giant and I don't think it will be a
problem with other mutexes, so I'd prefer a solution not quite so tailored to
this particular behavior of Giant.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Patch sets to date and timing tests with Giant out of userre
On 19-Feb-02 Terry Lambert wrote: Julian Elischer wrote: The fully safe version of this code is: td-td_retval[0] = td-td_ucred-cr_ruid; td-td_retval[1] = td-td_ucred-cr_uid; return (0); because td-td_ucred is read-only for it's whole existance. ??? Are you sure that td-td_ucred can't change in the middle, to point to a different ucred, as a result of kernel preemption? Yes. A thread's ucred pointer is constant teh entire time that it is in the kernel. If we get preempted who cares. We will still be teh same thread when we continue executing. :) -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ports/34908: libpng port makes bad dynamic library on -CURRENT
Hi -current, I ventured into this brave new world a few days ago and ran into this very problem. Alexander's patch (along with a make install in /usr/src/gnu/usr.bin/binutils) fixed it, as advertised. Maybe this can now be committed? --Stijn -- Help Wanted: Telepath. You know where to apply. msg34978/pgp0.pgp Description: PGP signature
Re: Patch to improve mutex collision performance
On Monday, 18 February 2002 at 15:38:07 -0500, Jake Burkholder wrote: Apparently, On Mon, Feb 18, 2002 at 11:51:44AM -0800, Matthew Dillon said words to the effect of; I'm fairly sure JHB does not have a patch to address this but, please, be my guest and check P4. Actually he does. Maybe you should have checked p4 first yourself. Well, maybe, like me, he doesn't know how. I only recently learnt of the existence of this repo, and I still don't know where it is. It certainly wasn't announced on the SMP mailing list. I've seen a few references to p4 there, but no indication of how to access the repo. What John's patch does is spin while the lock owner is running on another cpu. Spinning while there are no other processes on the run queues as well makes sense but you'll also be doing a lot of acquires and releases of sched_lock. I must be misinterpreting this statement. Under what circumstances do you spin? Yes, I read the while the owner is running in another CPU, but the way I read that, it turns the blocking lock into a spin lock. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RE: Patch to improve mutex collision performance
This sounds better but why do we need a 'pause' at all? I don't
think spinning in this case will have any effect on power
consumption.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
:I would rather make the locks adaptive like so: (untested)
:
:--- //depot/projects/smpng/sys/conf/options 2002/02/08 13:19:07
:+++ //depot/user/jhb/lock/conf/options 2002/02/08 13:50:54
:@@ -56,6 +56,7 @@
:# mapped I/O
:
: # Miscellaneous options.
:+ADAPTIVE_MUTEXES
: BLEED
: COMPAT_43 opt_compat.h
: COMPAT_SUNOS opt_compat.h
:--- //depot/projects/smpng/sys/i386/include/cpufunc.h 2001/12/18 13:07:32
:+++ //depot/user/jhb/lock/i386/include/cpufunc.h2001/12/20 15:54:32
:@@ -550,6 +550,12 @@
:__asm __volatile(movl %0,%%dr7 : : r (sel));
: }
:
:+static __inline void
:+cpu_pause(void)
:+{
:+ __asm __volatile(pause);
:+}
:+
: static __inline critical_t
: cpu_critical_enter(void)
: {
:--- //depot/projects/smpng/sys/kern/kern_mutex.c2002/02/08 14:19:21
:+++ //depot/user/jhb/lock/kern/kern_mutex.c 2002/02/08 13:50:54
:@@ -34,6 +34,7 @@
: * Machine independent bits of mutex implementation.
: */
:
:+#include opt_adaptive_mutexes.h
: #include opt_ddb.h
:
: #include sys/param.h
:@@ -345,7 +354,22 @@
:continue;
:}
:
:+#if defined(SMP) defined(ADAPTIVE_MUTEXES)
:/*
:+* If the current owner of the lock is executing on another
:+* CPU, spin instead of blocking.
:+*/
:+ if (((struct thread *)(v MTX_FLAGMASK)-td_kse-kse_oncpu !=
:+ NOCPU) {
:+ mtx_unlock_spin(sched_lock);
:+#ifdef __i386__
:+ cpu_pause();
:+#endif
:+ continue;
:+ }
:+#endif /* SMP ADAPTIVE_MUTEXES */
:+
:+ /*
: * We deffinately must sleep for this lock.
: */
:mtx_assert(m, MA_NOTOWNED);
:@@ -433,6 +457,9 @@
:/* Give interrupts a chance while we spin. */
:critical_exit();
:while (m-mtx_lock != MTX_UNOWNED) {
:+#ifdef __i386__
:+ cpu_pause();
:+#endif
:if (i++ 1000)
:continue;
:if (i++ 6000)
:
:This is more a specific problem with Giant and I don't think it will be a
:problem with other mutexes, so I'd prefer a solution not quite so tailored to
:this particular behavior of Giant.
:
:--
:
:John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
:Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Patch to improve mutex collision performance
:On Monday, 18 February 2002 at 15:38:07 -0500, Jake Burkholder wrote: : Apparently, On Mon, Feb 18, 2002 at 11:51:44AM -0800, : Matthew Dillon said words to the effect of; : I'm fairly sure JHB does not have a patch to address this but, please, : be my guest and check P4. : : Actually he does. Maybe you should have checked p4 first yourself. : :Well, maybe, like me, he doesn't know how. I only recently learnt of :the existence of this repo, and I still don't know where it is. It :certainly wasn't announced on the SMP mailing list. I've seen a few :references to p4 there, but no indication of how to access the repo. : : What John's patch does is spin while the lock owner is running on : another cpu. Spinning while there are no other processes on the run : queues as well makes sense but you'll also be doing a lot of : acquires and releases of sched_lock. : :I must be misinterpreting this statement. Under what circumstances do :you spin? Yes, I read the while the owner is running in another :CPU, but the way I read that, it turns the blocking lock into a spin :lock. : :Greg I'm not interested in using P4. I think it's a mistake. That is, I think it is being severely overused. At the very least it is preventing me from comitting simple things to -current because as far as I can tell when you add up the junk sitting in P4 it touches almost every file in the kernel tree. Everything I've tried to work on has some hack sitting in P4 somewhere that somebody hasn't committed. Well, that sucks folks. I want to be able to work on -current. There are literally 20 or 30 procedures that I can document and/or instrument Giant in and commit to the main tree trivially, with almost no chance of breaking someone and I want to do that to get those routines out of the way. I have no interest in taking what should be a day's worth of work and stretching out into one or two weeks due to having to check P4 to see what hacks other people might have left sitting there for weeks or months (half of it stale now). It is a supreme waste of time. I would like to see John commit his ucred stuff with Giant instrumentation. If he doesn't want to do it then I would like him to give me permission to do it from my tree now. I see no reason why we should have to wait another X days or weeks to see this stuff in the main tree. It just makes no sense to me. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Version control software (was: Patch sets to date and timing tests with Giant out of userret.)
On Tuesday, 19 February 2002 at 16:44:06 -0800, David O'Brien wrote: On Tue, Feb 19, 2002 at 01:51:31PM -0700, M. Warner Losh wrote: Bitkeeper enforces the linux devleopment model to a large extent, In what way(s)? I'd be interested in this too. I've been using Bitkeeper for, well, Linux development, but I don't see anything which locks it in to that direction. Of course, Bitkeeper isn't free either, so there's no particular reason to prefer it to p4. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Perforce repo (was: Patch sets to date and timing tests with Giant out of userret.)
On Tuesday, 19 February 2002 at 0:00:19 -0800, Peter Wemm wrote: Julian Elischer wrote: I'd prefer to be working on a branch of CVS if it weren't for the people that would scream whenever I moved my merged tag up. (eek eek cvsup bloat). That way i would have a dozen people helping me but with my code in P4 I have me and occasionally Peter. Everybody who can commit to cvs on freefall also has p4 access. Well, I certainly missed this. The set of people who can help is exactly the same. In fact, we even have a couple of non-comitters with access. As I posted before, When? the instructions are in http://people.freebsd.org/~peter/p4cookbook.txt, and the 'p4newuser' command on freefall is what is run to activate it. If we want a majordomo [EMAIL PROTECTED] mailing list (or something like that, as an analog to [EMAIL PROTECTED]), I can have that set up as well. Am I the only person who, despite careful scrutiny, missed this announcement? I would have thought that this would at least have been worth a HEADS UP and prior discussion in -core. I've just checked my -core archive, and though we discuss this repo from time to time, there was nothing there to suggest that it was publicly available. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
FreeBSD Project management (was: Patch sets to date and timing tests with Giant out of userret.)
On Monday, 18 February 2002 at 23:04:03 -0800, Peter Wemm wrote: Matthew Dillon wrote: What a waste.. John has already done all this stuff already (using td_ucred instead of p_ucred) over the entire tree. Cheers, -Peter He didn't instrument Giant, and if you actually believe that one massive commit is going to be more stable then the piecemeal safe-mode commits I am making then you are smoking something. Or are you expecting John to commit his patchset piecemeal as well and test inbetween? If that is so, then he just wasted a whole lot time managing all this junk in P4 because, frankly, it only took me a few minutes to instrument the easier system calls. I spend far more time testing. So, John's last few months of work is junk then, is it? On Monday, 18 February 2002 at 23:22:28 -0800, Peter Wemm wrote: Matthew Dillon wrote: So, John's last few months of work is junk then, is it? Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] I'll tell you what is junk... patches for things like getuid() sitting in P4 (whether instrumented or not). That's junk. I'll tell what is NOT junk. What isn't junk are things like John's more complex patch to kern_descrip.c. There's real work involved there that can be salvaged, and which can be committed to the -current piecemeal if Giant is properly instrumented. The biggest problem is that all of this stuff is sitting in P4 and none of it belongs there. With all due respect, bullshit! The p4 tree exists only as an alternative to people having large uncommitted diffs sitting in checked out cvs trees. Mailing patches between people trying to work in parallel is a bigger waste of time. That is inherently single threaded. While I don't agree with dillon's tone, I can understand his frustration. There is a lack of communication in the SMP project. I might have done more myself if I had been able to follow it without being on IRC 24 hours a day. I suspect that this applies to other people as well. Note that dillon has suffered because of this. He has gone and done what looks like being unnecessary work. When he tries to commit it, he finds that somebody else has been working on it, and despite a kernel summit only a couple of days ago, he didn't know about it. I'm not picking on jhb here. This is the project's fault, not any individual's. We need some kind of project management to coordinate this effort, or the results will be seriously suboptimal. I would certainly not like to see dillon go away because it's too difficult to work with the project. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD Project management (was: Patch sets to date and timing tests with Giant out of userret.)
* Greg Lehey [EMAIL PROTECTED] [020220 18:26] wrote: I'm not picking on jhb here. This is the project's fault, not any individual's. We need some kind of project management to coordinate this effort, or the results will be seriously suboptimal. I would certainly not like to see dillon go away because it's too difficult to work with the project. First with the code complete has it go in. Seems pretty simple enough doesn't it? I've had quite enough of people telling others to hold off because i'll have the feature any day now, or that fix is in my local tree. Like I care about your local tree, it's useless from my point of view when it's not working and in the repo. And what the hell has happened to the usb stack? -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD Project management (was: Patch sets to date and timing tests with Giant out of userret.)
I'm not in the core of the SMP stuff (the closest I'll get is the networking stuff) but I wonder if there is: 1) A work list of things that need to be done. 2) If that list is easy to read/update. Has anyone considered a Wiki to do this kind of coordination? We used TWiki at my last employer to decent effect. Check out www.twiki.org. Later, George To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Perforce repo (was: Patch sets to date and timing tests withGiant out of userret.)
On Thu, 21 Feb 2002, Greg Lehey wrote: On Tuesday, 19 February 2002 at 0:00:19 -0800, Peter Wemm wrote: Am I the only person who, despite careful scrutiny, missed this announcement? I would have thought that this would at least have been worth a HEADS UP and prior discussion in -core. I've just checked my -core archive, and though we discuss this repo from time to time, there was nothing there to suggest that it was publicly available. Even better is that the stuff is exported to a CVS tree and CVSupped out so you can actually work on it. (of course the version numbers are wierd but that doesn't matter) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD Project management (was: Patch sets to date and timing tests with Giant out of userret.)
On Wed, 20 Feb 2002, George V. Neville-Neil wrote: :I'm not in the core of the SMP stuff (the closest I'll get is the :networking stuff) but I wonder if there is: Doesn't this belong on [EMAIL PROTECTED] so that SMP people could answer? : :1) A work list of things that need to be done. : :2) If that list is easy to read/update. : :Has anyone considered a Wiki to do this kind of coordination? We used :TWiki at my last employer to decent effect. Check out www.twiki.org. : :Later, :George : :To Unsubscribe: send mail to [EMAIL PROTECTED] :with unsubscribe freebsd-current in the body of the message : -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD Project management (was: Patch sets to date and timing tests with Giant out of userret.)
On Wednesday, 20 February 2002 at 18:35:37 -0800, Alfred Perlstein wrote: * Greg Lehey [EMAIL PROTECTED] [020220 18:26] wrote: I'm not picking on jhb here. This is the project's fault, not any individual's. We need some kind of project management to coordinate this effort, or the results will be seriously suboptimal. I would certainly not like to see dillon go away because it's too difficult to work with the project. First with the code complete has it go in. Seems pretty simple enough doesn't it? Too simple. It's not the code complete, it's the correct code to implement a part of the overall goal. And we should be working together, not duplicating each other's efforts. I've had quite enough of people telling others to hold off because i'll have the feature any day now, or that fix is in my local tree. That's a detail, though admittedly one that needs to be addressed. We have more serious issues. Last Friday I asked for an overall project plan, and I still haven't seen one. Yes, we had some useful discussions, but it's still not enough. If it took Sun 8 years of (relatively) careful project planning to get their SMP up to a reasonable standard, how can we hope to succeed if we don't even decide what we're trying to do? Two years ago I spoke with you on the phone about SMP, and said that I didn't think that the project could cope with such a pervasive change. That's why I was happy when BSD[Ii] dropped both the design and the code into our lap, and we had an SMP project manager (for all of 6 months). Looking back now, we're making the same old mistakes. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD Project management (was: Patch sets to date and timing tests with Giant out of userret.)
On Wednesday, 20 February 2002 at 21:42:48 -0500, Andrew R. Reiter wrote: On Wed, 20 Feb 2002, George V. Neville-Neil wrote: I'm not in the core of the SMP stuff (the closest I'll get is the networking stuff) but I wonder if there is: Doesn't this belong on [EMAIL PROTECTED] so that SMP people could answer? Only up to a point. My issues (and George's, for that matter) are the project management side of things. I'm copying -developers, but maybe we need a different list: I'm open to suggestions. Maybe it's a symptom of the problem that there's no project management list. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Perforce repo (was: Patch sets to date and timing tests with Giant out of userret.)
On Wed, Feb 20, 2002 at 06:31:14PM -0800, Julian Elischer wrote: On Thu, 21 Feb 2002, Greg Lehey wrote: On Tuesday, 19 February 2002 at 0:00:19 -0800, Peter Wemm wrote: Am I the only person who, despite careful scrutiny, missed this announcement? I would have thought that this would at least have been worth a HEADS UP and prior discussion in -core. I've just checked my -core archive, and though we discuss this repo from time to time, there was nothing there to suggest that it was publicly available. Even better is that the stuff is exported to a CVS tree and CVSupped out so you can actually work on it. (of course the version numbers are wierd but that doesn't matter) There is still missing an overview over the p4 collections. No - I'm not going to cvsup p4-all - I already had an increasing of 1G overnight without a single warning. A p4-self collection is also missing. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to improve mutex collision performance
Matthew Dillon wrote: I'm not interested in using P4. I think it's a mistake. That is, I think it is being severely overused. At the very least it is preventing me from comitting simple things to -current because as far as I can tell when you add up the junk sitting in P4 it touches almost every file in the kernel tree. Everything I've tried to work on has some hack sitting in P4 somewhere that somebody hasn't committed. By the same token, you have also stated: ] Well... try again. If something ought to be compatible in a piecemeal ]commit and isn't, then something unexpected happened and you need to ]find out what it was. Doing a full-on commit for something like the ]proc lock patch is far too dangerous. It's just too large a patch set ]and we know from experience (cam, softupdates, etc...) that having a ]small handful of people testing a large private patch is not going to ]find all the bugs. How do you reconcile these divergent points of view? I would like to see John commit his ucred stuff with Giant instrumentation. If he doesn't want to do it then I would like him to give me permission to do it from my tree now. I see no reason why we should have to wait another X days or weeks to see this stuff in the main tree. It just makes no sense to me. What large scale changes are OK, and what large scale changes are too dangerous? Do you have a set of rules, that would let us look at a patch set and instantly decide which of these two categories the code fell into? I'm not trying to be a jerk, but not everything can be broken down into 1 line commits, and not everything can be broken down into 8 line commits, or 64 line commits, or 512 line commits, etc. (if you'll forgive my proof by induction). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Version control software (was: Patch sets to date and timing tests with Giant out of userret.)
Greg Lehey wrote: On Tuesday, 19 February 2002 at 16:44:06 -0800, David O'Brien wrote: On Tue, Feb 19, 2002 at 01:51:31PM -0700, M. Warner Losh wrote: Bitkeeper enforces the linux devleopment model to a large extent, In what way(s)? I'd be interested in this too. I've been using Bitkeeper for, well, Linux development, but I don't see anything which locks it in to that direction. Of course, Bitkeeper isn't free either, so there's no particular reason to prefer it to p4. Bitkeeper is free if you publish your repository; P4 is free if you are a free software project. Otherwise, they cost. Both are barriers to commercial utilization of free code, in the same way. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
make release failure in kerberos
Hi Jacques, Make release fails here. Can it be your changes to kerberos? John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] === libexec/kdc ... cc -O -pipe -I/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/include -I/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc -I/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/lib/krb5 -I/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/lib/asn1 -I/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/lib/hdb -I/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/lib/roken -I/usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kuser -I/usr/obj/usr/src/kerberos5/libexec/kdc/../../lib/libasn1 -I/usr/obj/usr/src/kerberos5/libexec/kdc/../../lib/libhdb -I/usr/obj/usr/src/kerberos5/libexec/kdc -Wall -I/usr/src/kerberos5/libexec/kdc/../../include -I/usr/src/kerberos5/libexec/kdc/../../include -DHAVE_CONFIG_H -DINET6-c /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c: In function `create_reply_ticket': /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:254: syntax error before `ticket' /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:268: warning: implicit declaration of function `krb_create_ticket' /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:268: `ticket' undeclared (first use in this function) /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:268: (Each undeclared identifier is reported only once /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:268: for each function it appears in.) /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:282: warning: implicit declaration of function `krb_life_to_time' /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c: In function `do_authenticate': /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:405: `v4_realm' undeclared (first use in this function) /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:407: warning: implicit declaration of function `db_fetch4' /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:435: warning: implicit declaration of function `get_des_key' /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:483: warning: implicit declaration of function `krb_time_to_life' /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c: In function `do_getticket': /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:587: `ANAME_SZ' undeclared (first use in this function) /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:588: `INST_SZ' undeclared (first use in this function) /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:589: `REALM_SZ' undeclared (first use in this function) /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:599: `v4_realm' undeclared (first use in this function) /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:646: syntax error before `ticket' /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:651: `SNAME_SZ' undeclared (first use in this function) /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:654: `ticket' undeclared (first use in this function) /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:666: warning: implicit declaration of function `decomp_ticket' /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:651: warning: unused variable `sinstance' /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:650: warning: unused variable `sname' /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:589: warning: unused variable `prealm' /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:588: warning: unused variable `pinst' /usr/src/kerberos5/libexec/kdc/../../../crypto/heimdal/kdc/kaserver.c:587: warning: unused variable `pname' *** Error code 1 Stop in /usr/src/kerberos5/libexec/kdc. *** Error code 1 Stop in /usr/src/kerberos5/libexec. *** Error code 1 Stop in /usr/src/kerberos5. *** Error code 1 Stop in /usr/src/release. *** Error code 1 Stop in /home/src/release. End Thu Feb 21 01:27:59 SAST 2002 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to improve mutex collision performance
:Matthew Dillon wrote: : I'm not interested in using P4. I think it's a mistake. That is, I : think it is being severely overused. At the very least it is preventing : me from comitting simple things to -current because as far as I can tell : when you add up the junk sitting in P4 it touches almost every file : in the kernel tree. Everything I've tried to work on has some hack : sitting in P4 somewhere that somebody hasn't committed. : :By the same token, you have also stated: : :] Well... try again. If something ought to be compatible in a piecemeal :]commit and isn't, then something unexpected happened and you need to :]find out what it was. Doing a full-on commit for something like the :]proc lock patch is far too dangerous. It's just too large a patch set :]and we know from experience (cam, softupdates, etc...) that having a :]small handful of people testing a large private patch is not going to :]find all the bugs. : :How do you reconcile these divergent points of view? These are not divergent points of view. I am saying quite clearly that the ucred code and proc-locking code can be committed in a piecemeal fashion. In fact, good chunk of the proc locking code already has been with no ill effect on the tree - it might not be completely operational due to Giant, but just comitting it tests a great deal of infrastructure including potential lock order reversals and mismatched locks. That's the whole point of doing things this way. :What large scale changes are OK, and what large scale changes :are too dangerous? The best example I can think of is Julian's initial KSE commit, where he rearranged the proc structure. The rearrangement touched a huge number of files and the commit had to be made all at once, not file by file, due to the structural changes. :Do you have a set of rules, that would let us look at a patch :set and instantly decide which of these two categories the :code fell into? : :I'm not trying to be a jerk, but not everything can be broken :down into 1 line commits, and not everything can be broken down :into 8 line commits, or 64 line commits, or 512 line commits, :etc. (if you'll forgive my proof by induction). : :-- Terry This is getting a bit absurd. I am arguing a general principle here, you are not contributing anything by stretching it into an irrational statement. One line commits? Oh come on! I will say that the work *I* am doing on -current is mostly piecemeal in nature. I even expect the VM locking to wind up being piecemeal. Everything I have posted to date has been piecemeal. For example, the ucred patchset I posted does not patch all the ucred functions, it just patched the read-only functions. But as a side effect that gave me a basis to track down the other uses of Giant in the general syscall path. That was a good demarkation point for me. It is by no means the end... it is, as I have said, piecemeal. The result? I was able to immediately note the use of Giant in trap.c (the ucred clearing code) as well as its use in userret(), plus I could test a few of the ucred functions like getuid() and test the Giant instrumentation. So you see, a piecemeal commit can have a great ability to move the development process forward. When you spend weeks or months putting together an UBER-patch you do not get any of that... it's all delayed and when the patch finally goes in people wind up spending a lot of time testing the patch itself rather then working on the ramification of what the patch allows you to move on to. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to improve mutex collision performance
On 21-Feb-02 Greg Lehey wrote: On Monday, 18 February 2002 at 15:38:07 -0500, Jake Burkholder wrote: Apparently, On Mon, Feb 18, 2002 at 11:51:44AM -0800, Matthew Dillon said words to the effect of; I'm fairly sure JHB does not have a patch to address this but, please, be my guest and check P4. Actually he does. Maybe you should have checked p4 first yourself. Well, maybe, like me, he doesn't know how. I only recently learnt of the existence of this repo, and I still don't know where it is. It certainly wasn't announced on the SMP mailing list. I've seen a few references to p4 there, but no indication of how to access the repo. What John's patch does is spin while the lock owner is running on another cpu. Spinning while there are no other processes on the run queues as well makes sense but you'll also be doing a lot of acquires and releases of sched_lock. I must be misinterpreting this statement. Under what circumstances do you spin? Yes, I read the while the owner is running in another CPU, but the way I read that, it turns the blocking lock into a spin lock. Only in some cases. This is the classic way of implementing an adaptive mutex. You spin if the other thread is actually executing on another CPU (the idea being it will release the lock soon so you are better off avoiding the context switch) and block if it is not executing on another CPU (releasing the lock is already at least one context switch away, so we might as well switch). Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RE: Patch to improve mutex collision performance
On 21-Feb-02 Matthew Dillon wrote:
This sounds better but why do we need a 'pause' at all? I don't
think spinning in this case will have any effect on power
consumption.
The pause is extra stuff mostly needed for the HyperThreading stuff on the
Pentium4 and also it helps improve cache performance on the P4. Talk to Peter
about it. It's really a separate deal but this was a quick cut 'n paste. The
actual kernel preemption code will reduce the number of context switches back
and forth on mutex release since it only preempts the kernel for real-time (i.e.
interrupt) kernel threads. Currently we will preempt one non-RT kthread for
another. When I talked to the guy who worked on Irix's ithread stuff at
Usenix, he said that adaptive locks actually ended up hurting performance, so I
would prefer to not put this in until after preemption is in and then do some
testing to see if adaptive mutexes help or hurt more.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
:I would rather make the locks adaptive like so: (untested)
:
:--- //depot/projects/smpng/sys/conf/options 2002/02/08 13:19:07
:+++ //depot/user/jhb/lock/conf/options 2002/02/08 13:50:54
:@@ -56,6 +56,7 @@
:# mapped I/O
:
: # Miscellaneous options.
:+ADAPTIVE_MUTEXES
: BLEED
: COMPAT_43 opt_compat.h
: COMPAT_SUNOS opt_compat.h
:--- //depot/projects/smpng/sys/i386/include/cpufunc.h 2001/12/18 13:07:32
:+++ //depot/user/jhb/lock/i386/include/cpufunc.h2001/12/20 15:54:32
:@@ -550,6 +550,12 @@
:__asm __volatile(movl %0,%%dr7 : : r (sel));
: }
:
:+static __inline void
:+cpu_pause(void)
:+{
:+ __asm __volatile(pause);
:+}
:+
: static __inline critical_t
: cpu_critical_enter(void)
: {
:--- //depot/projects/smpng/sys/kern/kern_mutex.c2002/02/08 14:19:21
:+++ //depot/user/jhb/lock/kern/kern_mutex.c 2002/02/08 13:50:54
:@@ -34,6 +34,7 @@
: * Machine independent bits of mutex implementation.
: */
:
:+#include opt_adaptive_mutexes.h
: #include opt_ddb.h
:
: #include sys/param.h
:@@ -345,7 +354,22 @@
:continue;
:}
:
:+#if defined(SMP) defined(ADAPTIVE_MUTEXES)
:/*
:+* If the current owner of the lock is executing on another
:+* CPU, spin instead of blocking.
:+*/
:+ if (((struct thread *)(v MTX_FLAGMASK)-td_kse-kse_oncpu
:!=
:+ NOCPU) {
:+ mtx_unlock_spin(sched_lock);
:+#ifdef __i386__
:+ cpu_pause();
:+#endif
:+ continue;
:+ }
:+#endif /* SMP ADAPTIVE_MUTEXES */
:+
:+ /*
: * We deffinately must sleep for this lock.
: */
:mtx_assert(m, MA_NOTOWNED);
:@@ -433,6 +457,9 @@
:/* Give interrupts a chance while we spin. */
:critical_exit();
:while (m-mtx_lock != MTX_UNOWNED) {
:+#ifdef __i386__
:+ cpu_pause();
:+#endif
:if (i++ 1000)
:continue;
:if (i++ 6000)
:
:This is more a specific problem with Giant and I don't think it will be a
:problem with other mutexes, so I'd prefer a solution not quite so tailored to
:this particular behavior of Giant.
:
:--
:
:John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
:Power Users Use the Power to Serve! - http://www.FreeBSD.org/
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: FreeBSD Project management (was: Patch sets to date and timi
On 21-Feb-02 George V. Neville-Neil wrote: I'm not in the core of the SMP stuff (the closest I'll get is the networking stuff) but I wonder if there is: 1) A work list of things that need to be done. 2) If that list is easy to read/update. Has anyone considered a Wiki to do this kind of coordination? We used TWiki at my last employer to decent effect. Check out www.twiki.org. There is http://www.freebsd.org/smp/ If someone wanted to convert this over to Twiki, go for it. New ideas to add to the list are welcome as well. Later, George To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch to improve mutex collision performance
On Wednesday, 20 February 2002 at 23:48:12 -0500, John Baldwin wrote: On 21-Feb-02 Greg Lehey wrote: On Monday, 18 February 2002 at 15:38:07 -0500, Jake Burkholder wrote: Apparently, On Mon, Feb 18, 2002 at 11:51:44AM -0800, Matthew Dillon said words to the effect of; I'm fairly sure JHB does not have a patch to address this but, please, be my guest and check P4. Actually he does. Maybe you should have checked p4 first yourself. Well, maybe, like me, he doesn't know how. I only recently learnt of the existence of this repo, and I still don't know where it is. It certainly wasn't announced on the SMP mailing list. I've seen a few references to p4 there, but no indication of how to access the repo. What John's patch does is spin while the lock owner is running on another cpu. Spinning while there are no other processes on the run queues as well makes sense but you'll also be doing a lot of acquires and releases of sched_lock. I must be misinterpreting this statement. Under what circumstances do you spin? Yes, I read the while the owner is running in another CPU, but the way I read that, it turns the blocking lock into a spin lock. Only in some cases. This is the classic way of implementing an adaptive mutex. Well, no, the classic way of implementing an adaptive lock is to spin a little bit and then block. Alternatives would be to learn what's going on and then decide whether to spin or block, or how long to spin before blocking. I've never heard it applied to a choice of CPU. Obviously any spin lock shouldn't spin if the lock holder is in the same CPU. You spin if the other thread is actually executing on another CPU (the idea being it will release the lock soon so you are better off avoiding the context switch) and block if it is not executing on another CPU (releasing the lock is already at least one context switch away, so we might as well switch). If you're talking about Giant here, one of us is seriously misunderstanding something. The whole idea of Giant is that it should be a blocking lock, not a spin lock. Tell me I'm misunderstanding you. The very first project milestone at http://www.freebsd.org/smp/ read Convert the giant lock from spinning to blocking. You might say ah, but the average system call takes less time than a schedule. We can test that. I've run lmbench on zaphod and found: Scheduling overhead:18 µs Null syscall (1 CPU):9 µs Null syscall (2 CPUs): 57 µs So this doesn't stand up. Note also that if there are more than two CPUs, the loss of time is much more significant. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD Project management (was: Patch sets to date and timi
There is http://www.freebsd.org/smp/ If someone wanted to convert this over to Twiki, go for it. New ideas to add to the list are welcome as well. I'll install TWiki on my home server tomorrow and publish when I'm ready, probably a day or so if all goes well. Then people can try it out and if people like it that will be fine. I'll write up a short email with pointers etc. so people will have an idea what to expect. If people hate it, well there is always rm :-) Later, George -- George V. Neville-Neil [EMAIL PROTECTED] NIC:GN82 Those who would trade liberty for temporary security deserve neither - Benjamin Franklin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
