cvs commit: src/sys/amd64/amd64 mp_machdep.c src/sys/i386/i386 mp_machdep.c

[Coleman Kane]

Brooks Davis wrote:
> On Sat, Nov 10, 2007 at 06:25:03PM -0800, Colin Percival wrote:
>   
>> Maxim Sobolev wrote:
>>     
>>> For what it is worth I think Nate has the correct point. We should not
>>> force this setting upon each and every user if it can realistically
>>> affect only 0.0001% of our userbase.
>>>       
>> We're not forcing anything -- it's configurable via loader.conf.  All
>> we're talking about is changing the default value.
>>
>>     
>>> By the way, I wonder how sun4v (aka Niagara) fares in this respect. As
>>> long as I know, they use similar concept, when 8 physical cores can run
>>> 32 threads. Should we disable it by default there as well? ;-)
>>>       
>> I haven't seen any experiments done on sun4v, but I'm less concerned about
>> it since I believe sun4v boxes are used more often for large computing jobs
>> rather than for interactive logins with many untrusted users.  Of course,
>> if/when we have scheduler support for keeping different users on separate
>> cores, this should be applied to sun4v as well.
>>     
>
> Actually, webhosting is probably the most common use of sun4v systems.
> As such, I'd expect that virtual hosting with large numbers of untrusted
> users running code on the same machine to be fairly common.
>
> -- Brooks
>   
I second this. As a person who actually participated in their "Try and
you don't have to buy" program, they pitched the system as basically
tuned for a LAMP server (I guess that's FAMP for us, heh). Reading
reviews and tech docs, the platform seems pretty tuned to that workload.

--
Coleman Kane