Date: Sun, 11 Nov 2007 10:22:40 -0800 From: Nate Lawson <nate@root.org> To: Colin Percival <cperciva@freebsd.org> Cc: Maxim Sobolev <sobomax@FreeBSD.org>, Kris Kennaway <kris@FreeBSD.org>, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/amd64/amd64 mp_machdep.c src/sys/i386/i386 mp_machdep.c Message-ID: <47374870.1080706@root.org> In-Reply-To: <473667FF.2010005@freebsd.org> References: <200711081945.lA8JjKcW080540@repoman.freebsd.org> <47337724.9040108@FreeBSD.org> <47337940.6040909@root.org> <47340B74.9070004@freebsd.org> <4734B13C.6050008@root.org> <4735008D.7030600@FreeBSD.org> <473667FF.2010005@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47374870.1080706>