Eric Dumazet wrote:
> if !CONFIG_SMP, why even dereferencing boot_pda+PDA_cpu to get 0 ?
> and as PER_CPU(cpu_gdt_descr, %ebx) in !CONFIG_SMP doesnt need the a value in
> ebx, you can just do :
>
> #define CUR_CPU(reg) /* nothing */
>
Yep. On the other hand, I think that's an incredibly rare
On Wednesday 29 November 2006 00:12, Jeremy Fitzhardinge wrote:
> Hi Eric,
>
> Could you try this patch out and see if it makes much performance
> difference for you. You should apply this on top of the %fs patch I
> posted earlier (and use the %fs patch as the baseline for your
> comparisons).
On Wednesday 29 November 2006 00:12, Jeremy Fitzhardinge wrote:
Hi Eric,
Could you try this patch out and see if it makes much performance
difference for you. You should apply this on top of the %fs patch I
posted earlier (and use the %fs patch as the baseline for your
comparisons).
Hi
Eric Dumazet wrote:
if !CONFIG_SMP, why even dereferencing boot_pda+PDA_cpu to get 0 ?
and as PER_CPU(cpu_gdt_descr, %ebx) in !CONFIG_SMP doesnt need the a value in
ebx, you can just do :
#define CUR_CPU(reg) /* nothing */
Yep. On the other hand, I think that's an incredibly rare path
Eric Dumazet wrote:
> Seeing %gs prefixes used now by i386 port, I recalled seeing strange oprofile
> results on Opteron machines.
Hi Eric,
Could you try this patch out and see if it makes much performance
difference for you. You should apply this on top of the %fs patch I
posted earlier (and
Eric Dumazet wrote:
Seeing %gs prefixes used now by i386 port, I recalled seeing strange oprofile
results on Opteron machines.
Hi Eric,
Could you try this patch out and see if it makes much performance
difference for you. You should apply this on top of the %fs patch I
posted earlier (and
Ingo Molnar wrote:
> what point would there be in using it? It's not like the kernel could
> make use of the thread keyword anytime soon (it would need /all/
> architectures to support it) ...
The plan was to implement the x86 arch-specific percpu stuff to use it,
since it allows gcc better
Ingo Molnar wrote:
what point would there be in using it? It's not like the kernel could
make use of the thread keyword anytime soon (it would need /all/
architectures to support it) ...
The plan was to implement the x86 arch-specific percpu stuff to use it,
since it allows gcc better
8 matches
Mail list logo
