SMP VFS Part 2

[Julian Elischer]

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.