Wilkinson, Alex wrote: > 0n Thu, Dec 02, 2004 at 08:49:08AM +0100, Peter Holm wrote: > > >I run on a ASUS P4P800 with a Intel Celeron CPU 1.80GHz CPU and a > >76319MB <ST380011A/3.06> Seagate disk. The config is GENERIC with > >BREAK_TO_DEBUGGER added. My /etc/sysctl.conf contains > >kern.threads.virtual_cpu=16 + debug.ddb_use_printf=1. Uptime for > >the last three double panics were 1h23m12s, 1h1m27s and 4h35m45s. > > Curios, is the sysctl "kern.threads.virtual_cpu" used for debugging HTT > enabled CPUs ? > > -aW > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" no, it tunes the systems's idea of how many "virtual CPUS" it should provide to threaded programs.. You can pretend you have 4 CPUs on a UP system but then the 4 threads that are scheduled at the same time for a process will compete for teh single CPU. There is a kind-of 2 level scheduelr.. threaded programs allow NCPU threads to be made avaliable to teh system to be scheduled at the same time. The system then schedules them. When they block or complete, teh process can submit replacement threads to continue to use its CPU allocation.. It's 1/ Very crude. 2/ probably very suboptimal 3/ a good candidate for replacement by a PhD candidate somewhere. 4/ very easy to do and simple. The aim is to provide some fairness so that a proces with 999 threads doesn't take up 999 slots in the system scheduler and completely swamp an unthreaded process that can only take one slot. With this scheme we allow it to be SLIGHTLY unfair, by allowing it to use upto to NCPU slots.Received on Wed Jan 05 2005 - 06:05:31 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:25 UTC