Date: Tue, 7 Aug 2001 15:08:50 -0500 From: Alfred Perlstein <bright@mu.org> To: Bosko Milekic <bmilekic@technokratis.com> Cc: Matt Dillon <dillon@earth.backplane.com>, Terry Lambert <tlambert2@mindspring.com>, Mike Smith <msmith@FreeBSD.ORG>, Zhihui Zhang <zzhang@cs.binghamton.edu>, freebsd-hackers@FreeBSD.ORG Subject: Re: Allocate a page at interrupt time Message-ID: <20010807150850.V85642@elvis.mu.org> In-Reply-To: <20010807155510.A50114@technokratis.com>; from bmilekic@technokratis.com on Tue, Aug 07, 2001 at 03:55:10PM -0400 References: <200108070739.f777dmi08218@mass.dis.org> <3B6FB0AE.8D40EF5D@mindspring.com> <200108071655.f77Gt9M32808@earth.backplane.com> <3B703029.2BB6D25A@mindspring.com> <200108071919.f77JJ1d35789@earth.backplane.com> <20010807155510.A50114@technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Bosko Milekic <bmilekic@technokratis.com> [010807 14:51] wrote: > > On Tue, Aug 07, 2001 at 12:19:01PM -0700, Matt Dillon wrote: > > Cache line invalidation does not require an IPI. TLB > > shootdowns require IPIs. TLB shootdowns are unrelated to > > interrupt threads, they only occur when shared mmu mappings > > change. Cache line invalidation can waste cpu cycles -- > > when cache mastership changes occur between cpus due to > > threads being switched between cpus. I consider this a > > serious problem in -current. > > I don't think it's fair to consider this a serious problem seeing as > how, as far as I'm aware, we've intended to eventually introduce code that will > favor keeping threads running on one CPU on that same CPU as long as it is > reasonable to do so (which should be most of the time). > I think after briefly discussing with Alfred on IRC that Alfred has > some CPU affinity patches on the way, but I'm not sure if they address > thread scheduling with the above intent in mind or if they merely introduce > an _interface_ to bind a thread to a single CPU. They do both. :) You can bind a process to a runqueue _and_ at the same time as long as a process on another CPU doesn't have a much higher priority we'll take from our local pool. Basically we give processes that last ran on our own CPU a false priority boost. http://people.freebsd.org/~alfred/bind_cpu.diff + cpu = PCPU_GET(cpuid); + pricpu = runq_findbit(&runqcpu[cpu]); + pri = runq_findbit(rq); + CTR2(KTR_RUNQ, "runq_choose: pri=%d cpupri=%d", pri, pricpu); + if (pricpu != -1 && (pricpu < pri || pri == -1)) { + pri = pricpu; + rqh = &runqcpu[cpu].rq_queues[pri]; + } else if (pri != -1) { + rqh = &rq->rq_queues[pri]; + } else { + CTR1(KTR_RUNQ, "runq_choose: idleproc pri=%d", pri); + return (PCPU_GET(idleproc)); + } + p = TAILQ_FIRST(rqh); Actually I think this patch is stale, it doesn't have the priority boost, but basically you can put it in the if (pricpu != -1 && (pricpu < pri || pri == -1)) { clause sort of like this: if (pricpu != -1 && (pricpu - FUDGE < pri || pri == -1)) { Where FUDGE is the priority boost you want to give local processes. -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010807150850.V85642>