From owner-freebsd-smp Mon Nov 12 9:11:50 2001 Delivered-To: freebsd-smp@freebsd.org Received: from is2.mh.itc.u-tokyo.ac.jp (is2.mh.itc.u-tokyo.ac.jp [133.11.205.12]) by hub.freebsd.org (Postfix) with ESMTP id 5322337B419; Mon, 12 Nov 2001 09:11:44 -0800 (PST) Received: from is2.mh.itc.u-tokyo.ac.jp (is2.mh.itc.u-tokyo.ac.jp [127.0.0.1]) by is2.mh.itc.u-tokyo.ac.jp (Postfix) with ESMTP id 5CB50378253; Tue, 13 Nov 2001 02:11:38 +0900 (JST) Received: from mailhosting.itc.u-tokyo.ac.jp (IDENT:mirapoint@mailhosting.itc.u-tokyo.ac.jp [133.11.205.3]) by is2.mh.itc.u-tokyo.ac.jp (8.11.3/8.11.3) with ESMTP id fACHBcs06722; Tue, 13 Nov 2001 02:11:38 +0900 Received: from ring.myn.rcast.u-tokyo.ac.jp (cognac.myn.rcast.u-tokyo.ac.jp [157.82.66.106]) by mailhosting.itc.u-tokyo.ac.jp (Mirapoint) with ESMTP id AEJ12537; Tue, 13 Nov 2001 02:11:21 +0900 (JST) Date: Tue, 13 Nov 2001 02:12:45 +0900 Message-ID: From: Hiroharu Tamaru To: freebsd-smp@FreeBSD.org Cc: John Baldwin Subject: Re: cpu affinity In-Reply-To: References: User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At Mon, 12 Nov 2001 07:48:04 -0800 (PST), John Baldwin wrote: > > > On 12-Nov-01 Hiroharu Tamaru wrote: > > Hi. > > > > I was looking for any hack point to set CPU affinity. I > > found in version 1.3.2.1 of kern/kern_switch.c (a little > > before 4.4R) that it already had "trivial affinity" > > implemented in chooseproc(). Is this different from what > > you are describing here? or has this disappeared in > > -current during the switch to KSE? > > > > I wanted to have a dedicated dual CPU machine for numerical > > calculations with large memory. Since this is a dedicated > > machine any hack was fine for me if at all possible. The > > machine has not arrived yet, so I haven't tested it yet. > > > > Can I expect, on 4.4R, to have two calc programs running > > (mostly) on their own CPU if I set these two processes at, > > say, rtprio (so that the two will live in a seperate group > > wrt any other processes)? or I don't even need rtprio? or do > > I have everything mixed up? > > > > Thanks. > > It might work right in that case. If you only have 1 process, then it tends to > bounce back and forth between the CPUs, but if every CPU is loaded and none are > idle, you might be able to avoid that problem. > I see. So, the key here is not to idle any of the CPUs all the time. OK, then. I'll give it a try with one and two processes when the machine arrives, and see if it is worth hacking in the kernel. Originally, since what I need is just a hack, I was thinking to hard code that some processes are ignored by each CPU altogether in chooseproc() (one CPU ignores one calc program, and the other CPU ignores the other), though, at the moment, I don't know what to use for the "label". I assume it should be something tied to a process that can be set by the process itself, and that can easily be seen by chooseproc(). Maybe, I'd steal a byte in p->p_pad, and add a syscall to register a asigned cpuid there, and ignore this process if the other CPU finds it in the run queue? Or maybe just using some arbitrary field like p->p_nice as a label, and get away even without writing a syscall would work for a dedicated system? If there's something obvious to use for the label, please advise me of it. Is this a Bad Idea even as a hack? or is it practical enough for a dedicated system? > > At Sat, 10 Nov 2001 13:27:37 -0800 (PST), > > John Baldwin wrote: > >> > >> > >> On 10-Nov-01 Andrew R. Reiter wrote: > >> > > >> > Do we have planes to implement some sort of mechanism for supporting cpu > >> > affinity? That'd be a pretty cool thing to have when 5.0 release time > >> > comes around. > >> > >> In theory that is to be part of KSE where a KSE will choose a thread that > >> last > >> ran on the current CPU over another thread in the same group. > > > > -- > > Hiroharu Tamaru > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-smp" in the body of the message > > -- > > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ -- Hiroharu Tamaru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message