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
kmacy at freebsd.org
Sat Nov 22 16:51:59 PST 2008
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
More information about the svn-src-head
mailing list