svn commit: r185162 - in head: . sys/amd64/include sys/arm/include sys/conf sys/dev/bce sys/dev/cxgb sys/dev/cxgb/sys sys/dev/cxgb/ulp/iw_cxgb sys/dev/mxge sys/dev/nxge sys/i386/include sys/i386/in...

[Kip Macy]

On Sat, Nov 22, 2008 at 11:08 PM, Scott Long <scottl at samsco.org> wrote:
> Kostik Belousov wrote:
>>
>> On Sat, Nov 22, 2008 at 03:05:22PM -0700, Scott Long wrote:
>>>
>>> A neat hack would be for the kernel linker to scan the text and do a
>>> drop-in replacement of the opcode that is appropriate for the platform.
>>> I can't see how a CPU_XXX definition would work because it's just a
>>> compile time construct, one that can be included with any kernel
>>> compile.
>>
>> Yes, it is possible to do that. Less drastic change is to directly
>> check features. I moved slow code to separate section to eliminate
>> unconditional jump in fast path.
>> Only compile-tested.
>>
>
> As long as it works, I think it's a step in the right direction; I'm
> assuming that cpu_feature is a symbol filled in at runtime and not a
> macro for the cpuid instruction, right?
>
> Scott
>

i386/include/md_var.h:
<..>
extern  u_int   cpu_exthigh;
extern  u_int   cpu_feature;
extern  u_int   cpu_feature2;
extern  u_int   amd_feature;
extern  u_int   amd_feature2;
<...>

I'm not thrilled with it, but we can revisit the issue if it makes a
measurable difference on someone's workload.

Thanks,
Kip







-- 
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis