Date: Tue, 13 Nov 2001 02:12:45 +0900 From: Hiroharu Tamaru <tamaru@myn.rcast.u-tokyo.ac.jp> To: freebsd-smp@FreeBSD.org Cc: John Baldwin <jhb@FreeBSD.org> Subject: Re: cpu affinity Message-ID: <sa6g07jdib6.wl@ring.myn.rcast.u-tokyo.ac.jp> In-Reply-To: <XFMail.011112074804.jhb@FreeBSD.org> References: <sa6hes0ceg9.wl@ring.myn.rcast.u-tokyo.ac.jp> <XFMail.011112074804.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?sa6g07jdib6.wl>