Date: Sun, 28 Nov 1999 16:21:52 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au> Cc: freebsd-arch@freebsd.org Subject: Re: Threads stuff Message-ID: <199911290021.QAA47007@apollo.backplane.com> References: <Pine.BSF.4.10.9911271542410.544-100000@current1.whistle.com> <3840B1EC.4614AAF0@vigrid.com> <199911281721.JAA45015@apollo.backplane.com> <38417A7F.B23C701D@vigrid.com> <99Nov29.111117est.40352@border.alcanet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
:On 1999-Nov-29 05:54:55 +1100, Daniel M. Eischen wrote:
:>Do we really want to be able to bind a _thread_ to a CPU?
:
:Yes.
:
:> Wouldn't it be sufficient to be able to bind a process to a CPU?
:
:Not really. If a process has multiple threads, it makes sense to be
:able to specify CPU affinity for each thread, since each thread can
:be scheduled independently.
:
:If you've got a multi-threaded process, I'm not sure why you'd want to
:bind it as a whole to a single CPU. This implies that only one thread
:can ever execute at once - which removes one major use for threads.
:
:Peter
And unless the cpu is reserved, the best that you can do in a general
purpose system (or in a system running several multi-threaded
applications) is to bind a thread to a 'virtual' cpu. For most
purposes, you simply want to supply a hint to the kernel rather then
actually try to enforce a hard requirement. A UTS can supply the hint,
but cannot actually do the physical assignment without a ridiculous
amount of complexity.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911290021.QAA47007>