Hi Paul,
I found you could find the information you needed about CPU
topology by query processor physical sharing relationship, please take a
look at pghw_find_pg() in uts/common/os/pghw.c. But they are not public
DDI interfaces.
Paul Durrant <mailto:[EMAIL PROTECTED]> wrote:
> Wesley Shao wrote:
>>
>> So in the world of windows, does the OS provide driver the
>> information on how many CPUs you have in the system, and the
>> relationships among the cores and strands (sharing L1 or L2 cache,
>> etc)?
>
> Nope. All you've got is the number of CPUs; we have to do intrinsic
> CPUID calls to get package/core/thread info. and infer cache info.
> from that. At least we can get this info. on Solaris without having
> to resort to intrinsics.
>
>>
>> The "policy setting" you mentioned above, did you mean some policies
>> the OS already support and driver picks one of them or do you mean
>> the driver comes up with its own set of policies and select one
>> based on the cpu information?
>>
>
> Windows supports several interrupt distribution policies. See
> http://msdn2.microsoft.com/en-us/library/aa491499.aspx
>
>> If I am not mistaken, you are hoping the OS can provide cpu
>> information. Can you be a little more specific on what type of info
>> your driver would require, in order to make intelligent traffic
>> routing decisions?
>>
>
> Usually you don't really want multiple threads contending for whatever
> the bottleneck in the system is. In most cases with current Intel
> chipsets this is the L2 cache or the front-side bus. You therefore
> want information about how the CPUs in the system are laid out so
> that the driver can decide which of the set of MSI-X interrupts it
> has bound to those various CPUs it actually wants to use so as not to
> end up with pointless resource contention. Usually it is only the
> driver which has the knowledge of what the data-flow will be so
> really it is only the driver that can make such a decision.
> The best solution from my point of view would be a call to get me N
> interrupts (which already exists in Solaris, acpi_msix_max and
> ddi_msix_alloc_limit having been hacked) and then a call to bind each
> of those interrupts to a specific CPU once the driver has worked out
> which CPUs would be optimal. This call, as far as I know, does not
> exist so we have to over-allocate interrupts using another hack to
> set the apic_intr_policy and then cherry-pick the subset that will
> cause the least resource contention.
>
> Paul
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
