Date: Thu, 25 Nov 2010 10:35:49 -0500 From: Attilio Rao <attilio@freebsd.org> To: Andriy Gapon <avg@freebsd.org> Cc: Garrett Cooper <yanegomi@gmail.com>, freebsd-hackers@freebsd.org Subject: Re: Best way to determine if an IRQ is present Message-ID: <AANLkTi=y8Pdg88PNy%2Brd05Sk3QH3KmvKLePZkerj02nM@mail.gmail.com> In-Reply-To: <4CEE816C.4060306@freebsd.org> References: <AANLkTi=%2ByXVrcWDC1QZLA0JWNOQjWG%2Bud_BmwiMXAMXt@mail.gmail.com> <201011220924.53709.jhb@freebsd.org> <4CEBDD42.5010007@freebsd.org> <4CEE80B1.6000602@FreeBSD.org> <4CEE816C.4060306@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2010/11/25 Andriy Gapon <avg@freebsd.org>: > on 25/11/2010 17:28 John Baldwin said the following: >> Andriy Gapon wrote: >>> on 22/11/2010 16:24 John Baldwin said the following: >>>> Well, the real solution is actually larger than described in the PR. = =C2=A0What you >>>> really want to do is take the logical CPUs offline when they are "halt= ed". >>>> Taking a CPU offline should trigger an EVENTHANDLER that various bits = of code >>>> could invoke. =C2=A0In the case of platforms that support binding inte= rrupts to CPUs >>>> (x86 and sparc64 at least), they would install an event handler that s= earches >>>> the MD interrupt tables (e.g. the interrupt_sources[] array on x86) an= d move >>>> bound interrupts to other CPUs. =C2=A0However, I think all the interru= pt >>>> bits will be MD, not MI. >>> >>> That's a good idea and a comprehensive approach. >>> One minor technical detail - should an offlined CPU be removed from all= _cpus >>> mask/set? >> >> That's tricky. =C2=A0In other e-mails I've had on this topic, the idea h= as been to have >> a new online_cpus mask and maybe a CPU_ONLINE() test macro =C2=A0similar= to >> CPU_ABSENT(). =C2=A0In that case, an offline CPU should still be in all_= cpus, but many >> places that use all_cpus would need to use online_cpus instead. >> > > This sounds like a plan. > CPU_FOREACH_ONLINE() could also come handy, > Thanks! One of the biggest issues here is that these bitmasks become no-more fixed for the kernel timelife, but you need proper locking to access them. I recall that one of the point for this plan is to benchmark and eventually optimize performance (as it is easilly feasible) on writing for rmlocks. In order to have a fully effective plan, there are several nits that need to be addressed here, I may have collected somewhere in a file, when I find it I will send to you. Attilio --=20 Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=y8Pdg88PNy%2Brd05Sk3QH3KmvKLePZkerj02nM>