update on running FreeBSD on xen
The curious can track its status (known bugs, feature plans, release plans, etc.) at: http://www.fsmware.com/xenofreebsd/7.0/STATUS It is in perforce under //depot/projects/xen3 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: An idea of remove MUTEX_WAKE_ALL
Daniel Eischen wrote: On Tue, 3 Jan 2006, Scott Long wrote: for a bit if the current lock owner is running on another CPU? Do we currently do that? (*) No, I am not referring to spin mutexes. Adaptive mutexes are enabled by default and have been for at least a year. Ahh, then that's what they (Adaptive) do. Well, it's a bit different from Solaris, I believe. They do not sleep after a certain number of contested spins, and instead just continue to spin. As we reduce the coverage of large contested locks (like Giant) this becomes much less of performance problem, though. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: An idea of remove MUTEX_WAKE_ALL
On Tue, 3 Jan 2006, Scott Long wrote: > > for a bit if the current lock owner is running on another CPU? > > Do we currently do that? > > > > (*) No, I am not referring to spin mutexes. > > > > Adaptive mutexes are enabled by default and have been for at least a > year. Ahh, then that's what they (Adaptive) do. -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: An idea of remove MUTEX_WAKE_ALL
Daniel Eischen wrote: On Tue, 3 Jan 2006, John Baldwin wrote: On Sunday 01 January 2006 02:21 am, prime wrote: Hi hackers, I have an idea about remove the kernel option MUTEX_WAKE_ALL. When we unlock the mutex(in _mtx_unlock_sleep),we can directly give the lock to the first thread waiting on the turnstile.And a thread gets the mutex after he returned from turnstile_wait so he can simply jump out the _obtain_lock loop in _mtx_lock_sleep. This makes a mutex always be owned by a thread when there are threads waiting on the turnstile,so priority inheritance can work now. This idea need only a few changes in kern/kern_mutex.c .But when NO_ADAPTIVE_MUTEXS not set,it makes threads that spinning on other CPU to get the mutex have to spin for a long time,and this makes the short term mutex more expensive(maybe should use spin mutex instead). What do think about the idea? Thanks. Sun actually found that the performance was better when you did MUTEX_WAKE_ALL because once you woke up N threads, if they don't all resume at once then they will acquire the lock in sequence and the lock acquires and releaes will all be simple ones rather than all being the complicated contested case. There are more details in _Solaris Internals_. Yes, but doesn't this partly rely on having the threads spin(*) for a bit if the current lock owner is running on another CPU? Do we currently do that? (*) No, I am not referring to spin mutexes. Adaptive mutexes are enabled by default and have been for at least a year. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: An idea of remove MUTEX_WAKE_ALL
On Tue, 3 Jan 2006, John Baldwin wrote: > On Sunday 01 January 2006 02:21 am, prime wrote: > > Hi hackers, > >I have an idea about remove the kernel option MUTEX_WAKE_ALL. > >When we unlock the mutex(in _mtx_unlock_sleep),we can directly > > give the lock to the first thread waiting on the turnstile.And a > > thread gets the mutex after he returned from turnstile_wait so he > > can simply jump out the _obtain_lock loop in _mtx_lock_sleep. > > This makes a mutex always be owned by a thread when there are threads > > waiting on the turnstile,so priority inheritance can work now. > >This idea need only a few changes in kern/kern_mutex.c .But when > > NO_ADAPTIVE_MUTEXS not set,it makes threads that spinning on other CPU > > to get the mutex have to spin for a long time,and this makes the short > > term mutex more expensive(maybe should use spin mutex instead). > > > > What do think about the idea? Thanks. > > Sun actually found that the performance was better when you did MUTEX_WAKE_ALL > because once you woke up N threads, if they don't all resume at once then > they will acquire the lock in sequence and the lock acquires and releaes will > all be simple ones rather than all being the complicated contested case. > There are more details in _Solaris Internals_. Yes, but doesn't this partly rely on having the threads spin(*) for a bit if the current lock owner is running on another CPU? Do we currently do that? (*) No, I am not referring to spin mutexes. -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: An idea of remove MUTEX_WAKE_ALL
On Sunday 01 January 2006 02:21 am, prime wrote: > Hi hackers, >I have an idea about remove the kernel option MUTEX_WAKE_ALL. >When we unlock the mutex(in _mtx_unlock_sleep),we can directly > give the lock to the first thread waiting on the turnstile.And a > thread gets the mutex after he returned from turnstile_wait so he > can simply jump out the _obtain_lock loop in _mtx_lock_sleep. > This makes a mutex always be owned by a thread when there are threads > waiting on the turnstile,so priority inheritance can work now. >This idea need only a few changes in kern/kern_mutex.c .But when > NO_ADAPTIVE_MUTEXS not set,it makes threads that spinning on other CPU > to get the mutex have to spin for a long time,and this makes the short > term mutex more expensive(maybe should use spin mutex instead). > > What do think about the idea? Thanks. Sun actually found that the performance was better when you did MUTEX_WAKE_ALL because once you woke up N threads, if they don't all resume at once then they will acquire the lock in sequence and the lock acquires and releaes will all be simple ones rather than all being the complicated contested case. There are more details in _Solaris Internals_. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problem about libnet on FreeBSD 6.0
> The problem is that libnet defines ether_addr without regard for the fact > that it's defined in our system headers. This is a bug in libnet, not > FreeBSD. Very interesting information :) Thanks for your reply (and happy new year !) -- unzip ; strip ; touch ; grep ; finger ; mount ; fsck ; more ; yes ; fsck ; umount ; sleep ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
devfs
Hi all i have a problem with devfs device hiding. My system is FreeBSD 6.0 (i386 and amd64, compiled from last sunday source (RELENG_6)) After mounting defs: #mount -t devfs devfs /tmp/proba first devfs command: # devfs -m /tmp/proba rule add type disk hide devfs rule: ioctl DEVFSIO_RADD: Input/output error the second command hangs: # devfs -m /tmp/proba rule add type disk hide command doesnt responds on HUP and TERM signals ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
