Skip site navigation (1)Skip section navigation (2)
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>