Colin Percival wrote: > Maxim Sobolev wrote: >> 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.
I don't think locking threads to cores by uid solves the general problem. Consider a web server, where processes run as the same uid but represent different customers. What we need is for the software components that deal with secrets (keys, passwords, etc.) to be able to specify "don't switch me out until I'm done" for a short quantum. Restricting access to that mechanism would also be needed to prevent DoS, same as realtime scheduling. -- Nate _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
