Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1221191 > unrolled thread

Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due to a kernel NULL pointer dereference)

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal  due to a kernel NULL pointer dereference) Baoquan He <bhe@redhat.com> - 2015-09-09 04:40 +0200
    Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due  to a kernel NULL pointer dereference) Sedat Dilek <sedat.dilek@gmail.com> - 2015-09-09 05:00 +0200
      Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due  to a kernel NULL pointer dereference) Sedat Dilek <sedat.dilek@gmail.com> - 2015-09-09 05:20 +0200
      Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal  due to a kernel NULL pointer dereference) Baoquan He <bhe@redhat.com> - 2015-09-09 05:30 +0200
        Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due  to a kernel NULL pointer dereference) Sedat Dilek <sedat.dilek@gmail.com> - 2015-09-09 05:50 +0200
          Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal  due to a kernel NULL pointer dereference) Peter Zijlstra <peterz@infradead.org> - 2015-09-09 15:00 +0200
            Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due  to a kernel NULL pointer dereference) Sedat Dilek <sedat.dilek@gmail.com> - 2015-09-12 23:30 +0200
              Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal  due to a kernel NULL pointer dereference) Peter Zijlstra <peterz@infradead.org> - 2015-09-14 09:20 +0200
                Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due  to a kernel NULL pointer dereference) Sedat Dilek <sedat.dilek@gmail.com> - 2015-09-14 09:40 +0200
                  Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due  to a kernel NULL pointer dereference) Sedat Dilek <sedat.dilek@gmail.com> - 2015-09-14 10:00 +0200
                  Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal  due to a kernel NULL pointer dereference) Peter Zijlstra <peterz@infradead.org> - 2015-09-14 11:00 +0200
                    Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal  due to a kernel NULL pointer dereference) Ingo Molnar <mingo@kernel.org> - 2015-09-14 11:40 +0200
                      Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal  due to a kernel NULL pointer dereference) Ingo Molnar <mingo@kernel.org> - 2015-09-14 12:00 +0200
                        Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due  to a kernel NULL pointer dereference) Sedat Dilek <sedat.dilek@gmail.com> - 2015-09-14 12:30 +0200
                          Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal  due to a kernel NULL pointer dereference) Ingo Molnar <mingo@kernel.org> - 2015-09-14 14:50 +0200
                      Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due  to a kernel NULL pointer dereference) Sedat Dilek <sedat.dilek@gmail.com> - 2015-09-14 12:00 +0200
                Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due  to a kernel NULL pointer dereference) Sedat Dilek <sedat.dilek@gmail.com> - 2015-09-14 09:50 +0200
                  Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due  to a kernel NULL pointer dereference) Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-14 20:00 +0200
                    Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal  due to a kernel NULL pointer dereference) Christoph Lameter <cl@linux.com> - 2015-09-14 20:30 +0200
                      Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due  to a kernel NULL pointer dereference) Austin S Hemmelgarn <ahferroin7@gmail.com> - 2015-09-14 20:40 +0200
                      Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal  due to a kernel NULL pointer dereference) Ingo Molnar <mingo@kernel.org> - 2015-09-15 08:20 +0200

Page 1 of 2  [1] 2  Next page →

#1221191 — Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due to a kernel NULL pointer dereference)

Seems it happened when call num_possible_cpus() which is a inline
function to call __bitmap_weight(). So did you check
lib/bitmap.c:__bitmap_weight() by objdump?

setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:1 nr_node_ids:1

Thanks
Baoquan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1221202 — Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due to a kernel NULL pointer dereference)

On Wed, Sep 9, 2015 at 4:29 AM, Baoquan He <bhe@redhat.com> wrote:
>
> Seems it happened when call num_possible_cpus() which is a inline
> function to call __bitmap_weight(). So did you check
> lib/bitmap.c:__bitmap_weight() by objdump?
>
> setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:1 nr_node_ids:1
>

[ CC->TO Denys ]

Hi Boaquan,

Thanks for your reply.

I tried a lot in the meantime :-).

For example I applied a patch from Denys Vlasenko <dvlasenk@redhat.com>...

commit 1a1d48a4a8fde49aedc045d894efe67173d59fe0
"linux/bitmap: Force inlining of bitmap weight functions"

...on top of Linux v4.2.

This resulted in the same call-trace in QEMU.

I hacked around to only re-build mm/percpu.c with GCC (rest with
CLANG) with some guidance from Linus (compiler warapper-script) etc.

What do you need for outputs?
objdump of lib/bitmap.o?
From both builds - with GCC and CLANG?

Please give me clear instructions, Thanks!

Regards,
- Sedat -

[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1a1d48a4a8fde49aedc045d894efe67173d59fe0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1221209 — Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due to a kernel NULL pointer dereference)

On Wed, Sep 9, 2015 at 5:04 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> On Wed, Sep 9, 2015 at 4:51 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>> On Wed, Sep 9, 2015 at 4:29 AM, Baoquan He <bhe@redhat.com> wrote:
>>>
>>> Seems it happened when call num_possible_cpus() which is a inline
>>> function to call __bitmap_weight(). So did you check
>>> lib/bitmap.c:__bitmap_weight() by objdump?
>>>
>>> setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:1 nr_node_ids:1
>>>
>>
>> [ CC->TO Denys ]
>>
>> Hi Boaquan,
>>
>> Thanks for your reply.
>>
>> I tried a lot in the meantime :-).
>>
>> For example I applied a patch from Denys Vlasenko <dvlasenk@redhat.com>...
>>
>> commit 1a1d48a4a8fde49aedc045d894efe67173d59fe0
>> "linux/bitmap: Force inlining of bitmap weight functions"
>>
>> ...on top of Linux v4.2.
>>
>> This resulted in the same call-trace in QEMU.
>>
>> I hacked around to only re-build mm/percpu.c with GCC (rest with
>> CLANG) with some guidance from Linus (compiler warapper-script) etc.
>>
>> What do you need for outputs?
>> objdump of lib/bitmap.o?
>> From both builds - with GCC and CLANG?
>>
>> Please give me clear instructions, Thanks!
>>
>> Regards,
>> - Sedat -
>>
>> [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1a1d48a4a8fde49aedc045d894efe67173d59fe0
>
> Below snippets against Linux v4.2 and Linux v4.2 plus llvmlinux-fixes
> (see file-attachment)...
> ( The patch "linux/bitmap: Force inlining of bitmap weight functions"
> from Denys was not applied. )
>
> [ lib-bitmap_o-objdump-drw_CLANG-3-7.txt ]
>
> 0000000000000670 <__bitmap_weight>:
>      670:       49 89 f8                mov    %rdi,%r8
>      673:       31 d2                   xor    %edx,%edx
>      675:       41 89 f1                mov    %esi,%r9d
>      678:       41 c1 e9 06             shr    $0x6,%r9d
>      67c:       b8 00 00 00 00          mov    $0x0,%eax
>      681:       74 26                   je     6a9 <__bitmap_weight+0x39>
>      683:       31 d2                   xor    %edx,%edx
>      685:       45 89 ca                mov    %r9d,%r10d
>      688:       4c 89 c1                mov    %r8,%rcx
>      68b:       0f 1f 44 00 00          nopl   0x0(%rax,%rax,1)
>      690:       48 8b 39                mov    (%rcx),%rdi
>      693:       e8 00 00 00 00          callq  698
> <__bitmap_weight+0x28>       694: R_X86_64_PC32
> __sw_hweight64-0x4
>      698:       89 d2                   mov    %edx,%edx
>      69a:       48 01 c2                add    %rax,%rdx
>      69d:       48 83 c1 08             add    $0x8,%rcx
>      6a1:       41 ff ca                dec    %r10d
>      6a4:       75 ea                   jne    690 <__bitmap_weight+0x20>
>      6a6:       44 89 c8                mov    %r9d,%eax
>      6a9:       40 f6 c6 3f             test   $0x3f,%sil
>      6ad:       74 1c                   je     6cb <__bitmap_weight+0x5b>
>      6af:       f7 de                   neg    %esi
>      6b1:       48 c7 c7 ff ff ff ff    mov    $0xffffffffffffffff,%rdi
>      6b8:       40 88 f1                mov    %sil,%cl
>      6bb:       48 d3 ef                shr    %cl,%rdi
>      6be:       49 23 3c c0             and    (%r8,%rax,8),%rdi
>      6c2:       e8 00 00 00 00          callq  6c7
> <__bitmap_weight+0x57>       6c3: R_X86_64_PC32
> __sw_hweight64-0x4
>      6c7:       01 d0                   add    %edx,%eax
>      6c9:       89 c2                   mov    %eax,%edx
>      6cb:       89 d0                   mov    %edx,%eax
>      6cd:       c3                      retq
>      6ce:       66 90                   xchg   %ax,%ax
>
> [ lib-bitmap_o-objdump-drw_GCC-4-9.txt ]
>
> 0000000000000d60 <__bitmap_weight>:
>  d60:   89 f1                   mov    %esi,%ecx
>  d62:   55                      push   %rbp
>  d63:   49 89 fa                mov    %rdi,%r10
>  d66:   c1 e9 06                shr    $0x6,%ecx
>  d69:   85 c9                   test   %ecx,%ecx
>  d6b:   48 89 e5                mov    %rsp,%rbp
>  d6e:   74 52                   je     dc2 <__bitmap_weight+0x62>
>  d70:   8d 41 ff                lea    -0x1(%rcx),%eax
>  d73:   48 89 fa                mov    %rdi,%rdx
>  d76:   45 31 c0                xor    %r8d,%r8d
>  d79:   4c 8d 0c c5 08 00 00 00         lea    0x8(,%rax,8),%r9
>  d81:   49 01 f9                add    %rdi,%r9
>  d84:   48 8b 3a                mov    (%rdx),%rdi
>  d87:   48 83 c2 08             add    $0x8,%rdx
>  d8b:   e8 00 00 00 00          callq  d90 <__bitmap_weight+0x30>
>  d8c: R_X86_64_PC32      __sw_hweight64-0x4
>  d90:   41 01 c0                add    %eax,%r8d
>  d93:   4c 39 ca                cmp    %r9,%rdx
>  d96:   75 ec                   jne    d84 <__bitmap_weight+0x24>
>  d98:   40 f6 c6 3f             test   $0x3f,%sil
>  d9c:   44 89 c0                mov    %r8d,%eax
>  d9f:   74 1f                   je     dc0 <__bitmap_weight+0x60>
>  da1:   f7 de                   neg    %esi
>  da3:   89 ca                   mov    %ecx,%edx
>  da5:   48 c7 c0 ff ff ff ff    mov    $0xffffffffffffffff,%rax
>  dac:   89 f1                   mov    %esi,%ecx
>  dae:   48 d3 e8                shr    %cl,%rax
>  db1:   49 23 04 d2             and    (%r10,%rdx,8),%rax
>  db5:   48 89 c7                mov    %rax,%rdi
>  db8:   e8 00 00 00 00          callq  dbd <__bitmap_weight+0x5d>
>  db9: R_X86_64_PC32      __sw_hweight64-0x4
>  dbd:   44 01 c0                add    %r8d,%eax
>  dc0:   5d                      pop    %rbp
>  dc1:   c3                      retq
>  dc2:   85 f6                   test   %esi,%esi
>  dc4:   74 19                   je     ddf <__bitmap_weight+0x7f>
>  dc6:   f7 de                   neg    %esi
>  dc8:   48 c7 c0 ff ff ff ff    mov    $0xffffffffffffffff,%rax
>  dcf:   45 31 c0                xor    %r8d,%r8d
>  dd2:   89 f1                   mov    %esi,%ecx
>  dd4:   48 d3 e8                shr    %cl,%rax
>  dd7:   49 23 02                and    (%r10),%rax
>  dda:   48 89 c7                mov    %rax,%rdi
>  ddd:   eb d9                   jmp    db8 <__bitmap_weight+0x58>
>  ddf:   31 c0                   xor    %eax,%eax
>  de1:   5d                      pop    %rbp
>  de2:   c3                      retq
>  de3:   66 66 66 66 2e 0f 1f 84 00 00 00 00 00  data32 data32 data32
> nopw %cs:0x0(%rax,%rax,1)
>

Looking at the GCC bug-report [1] mentionned in [2] I have set here...

CONFIG_OPTIMIZE_INLINING=y

- Sedat -

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
[2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1a1d48a4a8fde49aedc045d894efe67173d59fe0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1221212

Hi Sedat,

On 09/09/15 at 04:51am, Sedat Dilek wrote:
> On Wed, Sep 9, 2015 at 4:29 AM, Baoquan He <bhe@redhat.com> wrote:
> commit 1a1d48a4a8fde49aedc045d894efe67173d59fe0
> "linux/bitmap: Force inlining of bitmap weight functions"
> 
> ...on top of Linux v4.2.
> 
> This resulted in the same call-trace in QEMU.
> 
> I hacked around to only re-build mm/percpu.c with GCC (rest with
> CLANG) with some guidance from Linus (compiler warapper-script) etc.

Sorry, from below log message and code flow I didn't get what's wrong
with it. I am working on another issue which gives me much headache,
don't hvae time to look into the the disassembling code now. But if GCC
built code works, it should be related to compiler issues. You can try
more tests, e.g build percpu.c bitmap.c with GCC. Maybe other people
can give suggestions.

Sorry again, Sedat.

setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:1 nr_node_ids:1

arch/x86/kernel/setup_percpu.c:setup_per_cpu_areas() ->
mm/percpu.c : pcpu_embed_first_chunk() ->
mm/percpu.c:pcpu_build_alloc_info() ->
include/linux/cpumask.h:
#define num_possible_cpus()     cpumask_weight(cpu_possible_mask)
static inline unsigned int cpumask_weight(const struct cpumask *srcp)                                                                            
{
        return bitmap_weight(cpumask_bits(srcp), nr_cpumask_bits);
}

include/linux/bitmap.h:
static inline int bitmap_weight(const unsigned long *src, unsigned int nbits)                                                                    
{
        if (small_const_nbits(nbits))
                return hweight_long(*src & BITMAP_LAST_WORD_MASK(nbits));
        return __bitmap_weight(src, nbits);
}

lib/bitmap.c:
int __bitmap_weight(const unsigned long *bitmap, unsigned int bits)
{
        unsigned int k, lim = bits/BITS_PER_LONG;
        int w = 0;

        for (k = 0; k < lim; k++)                                                                                                                
                w += hweight_long(bitmap[k]);

        if (bits % BITS_PER_LONG)
                w += hweight_long(bitmap[k] & BITMAP_LAST_WORD_MASK(bits));
        
        return w;
}
EXPORT_SYMBOL(__bitmap_weight);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1221214 — Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due to a kernel NULL pointer dereference)

On Wed, Sep 9, 2015 at 5:25 AM, Baoquan He <bhe@redhat.com> wrote:
> Hi Sedat,
>
> On 09/09/15 at 04:51am, Sedat Dilek wrote:
>> On Wed, Sep 9, 2015 at 4:29 AM, Baoquan He <bhe@redhat.com> wrote:
>> commit 1a1d48a4a8fde49aedc045d894efe67173d59fe0
>> "linux/bitmap: Force inlining of bitmap weight functions"
>>
>> ...on top of Linux v4.2.
>>
>> This resulted in the same call-trace in QEMU.
>>
>> I hacked around to only re-build mm/percpu.c with GCC (rest with
>> CLANG) with some guidance from Linus (compiler warapper-script) etc.
>
> Sorry, from below log message and code flow I didn't get what's wrong
> with it. I am working on another issue which gives me much headache,
> don't hvae time to look into the the disassembling code now. But if GCC
> built code works, it should be related to compiler issues. You can try
> more tests, e.g build percpu.c bitmap.c with GCC. Maybe other people
> can give suggestions.
>
> Sorry again, Sedat.
>

Hi Baoquan,

OK, I understand your situation and kernel folks are within
merge-window or you have to concentrate on your daily work etc.

I have found some more playground

The article "Force a function to be inline in Clang/LLVM" from
<http://stackoverflow.com> in [1] says...

"There is a good solution if compiling with C99 which is Clang's
default. Its simply using inline attribute.

inline void foo() {}

[...]

So in order to guarantee that the function is inlined:

1. Don’t use static inline.
2. Don’t add another implementation for the function that doesn't have
inline attribute.
3. You must use optimization. But even if there isn't optimization the
compilation will fail which is good.
4. Make sure not to compile with GNU89."

So I added to Linux main Makefile...

$ git diff
diff --git a/Makefile b/Makefile
index 0e333fd142a1..e1723367ece4 100644
--- a/Makefile
+++ b/Makefile
@@ -702,6 +702,14 @@ KBUILD_CFLAGS += $(call cc-disable-warning,
tautological-compare)
 # See modpost pattern 2
 KBUILD_CFLAGS += $(call cc-option, -mno-global-merge,)

+# Force a function to be inline in Clang/LLVM
+# http://stackoverflow.com/questions/25602813/force-a-function-to-be-inline-in-clang-llvm
+# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
+# http://marc.info/?t=144156156700001&r=1&w=2
+ifdef CONFIG_OPTIMIZE_INLINING
+KBUILD_CFLAGS += $(call cc-option,-always-inline)
+endif
+
 else

 KBUILD_CFLAGS += $(call cc-option,-fno-delete-null-pointer-checks,)

Some comments below...

Thanks in advance!

> setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:1 nr_node_ids:1
>
> arch/x86/kernel/setup_percpu.c:setup_per_cpu_areas() ->
> mm/percpu.c : pcpu_embed_first_chunk() ->
> mm/percpu.c:pcpu_build_alloc_info() ->
> include/linux/cpumask.h:
> #define num_possible_cpus()     cpumask_weight(cpu_possible_mask)
> static inline unsigned int cpumask_weight(const struct cpumask *srcp)
> {
>         return bitmap_weight(cpumask_bits(srcp), nr_cpumask_bits);
> }
>

s/inline/__always_inline/ ???

> include/linux/bitmap.h:
> static inline int bitmap_weight(const unsigned long *src, unsigned int nbits)
> {
>         if (small_const_nbits(nbits))
>                 return hweight_long(*src & BITMAP_LAST_WORD_MASK(nbits));
>         return __bitmap_weight(src, nbits);
> }
>

s/inline/__always_inline/ ???

Already realized in "linux/bitmap: Force inlining of bitmap weight
functions" upstream (see [3], but not available for Linux v4.2).

> lib/bitmap.c:
> int __bitmap_weight(const unsigned long *bitmap, unsigned int bits)
> {
>         unsigned int k, lim = bits/BITS_PER_LONG;
>         int w = 0;
>
>         for (k = 0; k < lim; k++)
>                 w += hweight_long(bitmap[k]);
>
>         if (bits % BITS_PER_LONG)
>                 w += hweight_long(bitmap[k] & BITMAP_LAST_WORD_MASK(bits));
>
>         return w;
> }
> EXPORT_SYMBOL(__bitmap_weight);
>

Thanks again.

- Sedat -

[1] http://stackoverflow.com/questions/25602813/force-a-function-to-be-inline-in-clang-llvm
[2] http://git.linuxfoundation.org/?p=llvmlinux.git;a=blob;f=arch/all/patches/compiler-gcc.patch
[3] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1a1d48a4a8fde49aedc045d894efe67173d59fe0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1221406

On Wed, Sep 09, 2015 at 12:05:50PM +0200, Sedat Dilek wrote:
> I can boot into a CLANG v3.7 compiled Linux-kernel when lib/bitmap is
> compiled with GCC (here: v4.9).
> 
> CONFIG_OPTIMIZE_INLINING has no effect on this.
> 
> Attached are the single llvmlinux patch for AMD64 (x86_64), my
> kernel-config and 2 objdumps with bitmap.o file alltogether.

I suggest you go tell the LLVM people their compiler is broken.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223466 — Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due to a kernel NULL pointer dereference)

On Wed, Sep 9, 2015 at 2:54 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, Sep 09, 2015 at 12:05:50PM +0200, Sedat Dilek wrote:
>> I can boot into a CLANG v3.7 compiled Linux-kernel when lib/bitmap is
>> compiled with GCC (here: v4.9).
>>
>> CONFIG_OPTIMIZE_INLINING has no effect on this.
>>
>> Attached are the single llvmlinux patch for AMD64 (x86_64), my
>> kernel-config and 2 objdumps with bitmap.o file alltogether.
>
> I suggest you go tell the LLVM people their compiler is broken.

It looks like an inline-optimization bug in CLANG when the compiler's
optimization-level is higher than -O2.

Level -O0 and -O1 are OK - I can boot in such Linux-kernel v4.2.

With Level -Oz when CONFIG_CC_OPTIMIZE_FOR_SIZE=y (equivalent to GCC's
-Os) the objdump looked sane but I cannot boot on bare metal.
Re-compiling lib/bitmap with -O0 or -O1 is fine again.

- Sedat -

[1] http://lists.linuxfoundation.org/pipermail/llvmlinux/2015-September/001355.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223870

On Sun, Sep 13, 2015 at 04:33:39AM +0200, Sedat Dilek wrote:
> > It looks like an inline-optimization bug in CLANG when the compiler's
> > optimization-level is higher than -O2.

> > [1] http://lists.linuxfoundation.org/pipermail/llvmlinux/2015-September/001355.html
> 
> After some discussion on #llvm it turned out to be a known issue in LLVMLinux!
> 
> Unfortunately, an existing patch [1] got archived which is still
> required to build x86_64 correctly.

> [1] http://git.linuxfoundation.org/?p=llvmlinux.git;a=blob_plain;f=arch/x86_64/patches/ARCHIVE/0029-Fix-ARCH_HWEIGHT-for-compilation-with-clang.patch;hb=HEAD

As long as LLVM cannot do things like that and requires full function
calls I cannot see it being a sensible compiler to use from a
performance POV.

There's a fairly large difference between an inline POPCNT instruction
and a full out-of-line function call.

/me goes back to ignoring LLVM for the time being.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223884 — Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due to a kernel NULL pointer dereference)

On Mon, Sep 14, 2015 at 9:12 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Sun, Sep 13, 2015 at 04:33:39AM +0200, Sedat Dilek wrote:
>> > It looks like an inline-optimization bug in CLANG when the compiler's
>> > optimization-level is higher than -O2.
>
>> > [1] http://lists.linuxfoundation.org/pipermail/llvmlinux/2015-September/001355.html
>>
>> After some discussion on #llvm it turned out to be a known issue in LLVMLinux!
>>
>> Unfortunately, an existing patch [1] got archived which is still
>> required to build x86_64 correctly.
>
>> [1] http://git.linuxfoundation.org/?p=llvmlinux.git;a=blob_plain;f=arch/x86_64/patches/ARCHIVE/0029-Fix-ARCH_HWEIGHT-for-compilation-with-clang.patch;hb=HEAD
>
> As long as LLVM cannot do things like that and requires full function
> calls I cannot see it being a sensible compiler to use from a
> performance POV.
>
> There's a fairly large difference between an inline POPCNT instruction
> and a full out-of-line function call.
>
> /me goes back to ignoring LLVM for the time being.

[ CC llvmlinux ML ]

Hi Peter,

Clear words and a clear statement!
( Men want clear statements see [1]. )

The issue was reported as LLVM PR #9457 [1] and the bug-history [2] says...

   Reported: 2011-03-11 07:27 CST by PaX Team

...so it is a known and old issue.

Cannot say if "ignoring" is really helpful or not :-).
Sanjoy Das (a LLVM/Clang developer) joined the vital discussion in the
thread (see [3])...

"[llvmlinux] [PATCH] x86/hweight: LLVMLinux: Fix __arch_hweight{32,
64}() for compilation with clang"

Beyond "fixing" or implementing missing (GCC) features on the LLVM-Clang-side...
People there have some discussion and ideas on a "workaround" or fix
it on the Linux-kernel-side.

Ignoring does not help - ignorance is a hard (hardest?) punishment for men.

I invite you to join the discussion at LLVMLinux...
As I know... "YES, you can." Linux x86/x86_64 (assembler) Kung-Fu.
( I admit I have not these skillz. )

Regards,
- Sedat -

[1] https://llvm.org/bugs/show_bug.cgi?id=9457
[2] https://llvm.org/bugs/show_activity.cgi?id=9457
[3] [1] http://lists.linuxfoundation.org/pipermail/llvmlinux/2015-September/001369.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223897 — Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due to a kernel NULL pointer dereference)

On Mon, Sep 14, 2015 at 9:35 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> On Mon, Sep 14, 2015 at 9:12 AM, Peter Zijlstra <peterz@infradead.org> wrote:
>> On Sun, Sep 13, 2015 at 04:33:39AM +0200, Sedat Dilek wrote:
>>> > It looks like an inline-optimization bug in CLANG when the compiler's
>>> > optimization-level is higher than -O2.
>>
>>> > [1] http://lists.linuxfoundation.org/pipermail/llvmlinux/2015-September/001355.html
>>>
>>> After some discussion on #llvm it turned out to be a known issue in LLVMLinux!
>>>
>>> Unfortunately, an existing patch [1] got archived which is still
>>> required to build x86_64 correctly.
>>
>>> [1] http://git.linuxfoundation.org/?p=llvmlinux.git;a=blob_plain;f=arch/x86_64/patches/ARCHIVE/0029-Fix-ARCH_HWEIGHT-for-compilation-with-clang.patch;hb=HEAD
>>
>> As long as LLVM cannot do things like that and requires full function
>> calls I cannot see it being a sensible compiler to use from a
>> performance POV.
>>
>> There's a fairly large difference between an inline POPCNT instruction
>> and a full out-of-line function call.
>>
>> /me goes back to ignoring LLVM for the time being.
>
> [ CC llvmlinux ML ]
>
> Hi Peter,
>
> Clear words and a clear statement!
> ( Men want clear statements see [1]. )
>
> The issue was reported as LLVM PR #9457 [1] and the bug-history [2] says...
>
>    Reported: 2011-03-11 07:27 CST by PaX Team
>
> ...so it is a known and old issue.
>
> Cannot say if "ignoring" is really helpful or not :-).
> Sanjoy Das (a LLVM/Clang developer) joined the vital discussion in the
> thread (see [3])...
>
> "[llvmlinux] [PATCH] x86/hweight: LLVMLinux: Fix __arch_hweight{32,
> 64}() for compilation with clang"
>
> Beyond "fixing" or implementing missing (GCC) features on the LLVM-Clang-side...
> People there have some discussion and ideas on a "workaround" or fix
> it on the Linux-kernel-side.
>
> Ignoring does not help - ignorance is a hard (hardest?) punishment for men.
>
> I invite you to join the discussion at LLVMLinux...
> As I know... "YES, you can." Linux x86/x86_64 (assembler) Kung-Fu.
> ( I admit I have not these skillz. )
>
> Regards,
> - Sedat -
>
> [1] https://llvm.org/bugs/show_bug.cgi?id=9457
> [2] https://llvm.org/bugs/show_activity.cgi?id=9457
> [3] [1] http://lists.linuxfoundation.org/pipermail/llvmlinux/2015-September/001369.html

For the sake of completeness...

Jan-Simon pointed to CLANG PR #24487 in [2]...

"Bug 24487 -clang fails to compile linux "ALTERNATIVE" (integrated-as)"

If someone is really interested in helping - join the discussion on
llvmlinux ML.

- Sedat -

[1] https://llvm.org/bugs/show_bug.cgi?id=24487
[2] http://lists.linuxfoundation.org/pipermail/llvmlinux/2015-September/001359.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223937

On Mon, Sep 14, 2015 at 09:35:04AM +0200, Sedat Dilek wrote:
> > /me goes back to ignoring LLVM for the time being.

> The issue was reported as LLVM PR #9457 [1] and the bug-history [2] says...
> 
>    Reported: 2011-03-11 07:27 CST by PaX Team
> 
> ...so it is a known and old issue.

> Beyond "fixing" or implementing missing (GCC) features on the LLVM-Clang-side...
> People there have some discussion and ideas on a "workaround" or fix
> it on the Linux-kernel-side.

Barring LLVM implementing the relevant function call attributes, you
could look at either generating the required thunks (as mentioned
earlier as a work-around) or at the very least validating that all
required thunks are present.

> I invite you to join the discussion at LLVMLinux...
> As I know... "YES, you can." Linux x86/x86_64 (assembler) Kung-Fu.
> ( I admit I have not these skillz. )

Its a matter of time for me; I simply do not have enough time as it is
so I have to make choices.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223976

* Peter Zijlstra <peterz@infradead.org> wrote:

> > I invite you to join the discussion at LLVMLinux... As I know... "YES, you 
> > can." Linux x86/x86_64 (assembler) Kung-Fu. ( I admit I have not these skillz. 
> > )
> 
> Its a matter of time for me; I simply do not have enough time as it is so I have 
> to make choices.

We are also willing to apply clean, sensible patches.

Alas that collection of llvm patches quoted in this thread:

  30 files changed, 188 insertions(+), 161 deletions(-)

had quite a few objectionable hacks in them.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223993

* Sedat Dilek <sedat.dilek@gmail.com> wrote:

> From my side... How can the correbolation be improved...?

The best workflow would be for someone to send patches that are considered clean 
enough.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1224008 — Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due to a kernel NULL pointer dereference)

On Mon, Sep 14, 2015 at 11:59 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Sedat Dilek <sedat.dilek@gmail.com> wrote:
>
>> From my side... How can the correbolation be improved...?
>
> The best workflow would be for someone to send patches that are considered clean
> enough.
>

What do you mean by "patches that are considered clean"?

"Clean" in the sense of is-not-a-hackery and/or
patch-does-not-follow-Linux-kernel-development-guidelines [1]?

[ EXAMPLES ]

[ commit subject-line ]

Like a "meaningful" subject-line...
I have seen patches which did not use commonly-used labels, like "x86/weight:".
( 'git log /path/to/file' tells someone how other's did it. )

[ commit message ]

Personally, I did not like the embedded commit-messages (change-log) -
it was sometimes not very helpful.
Helpful would be hints to a discussion thread (ML), bug-no in BTS,
output of a BROKEN build, etc.

...

Oh, if we all would follow Peter H. blog-article "On commit messages" [2].
( /me dreams of a better world. )

- Sedat -

[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches
[2] http://who-t.blogspot.de/2009/12/on-commit-messages.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1224102

* Sedat Dilek <sedat.dilek@gmail.com> wrote:

> On Mon, Sep 14, 2015 at 11:59 AM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Sedat Dilek <sedat.dilek@gmail.com> wrote:
> >
> >> From my side... How can the correbolation be improved...?
> >
> > The best workflow would be for someone to send patches that are considered 
> > clean enough.
> 
> What do you mean by "patches that are considered clean"?
> 
> "Clean" in the sense of is-not-a-hackery and/or
> patch-does-not-follow-Linux-kernel-development-guidelines [1]?

Both in the end.

> Oh, if we all would follow Peter H. blog-article "On commit messages" [2].
> ( /me dreams of a better world. )

So if _you_ start sending those patches then you need to fix known problems.
You don't have to keep the patches as-is as you found them, you are free to fix 
them, open source and all that.

Just start simple, with a single, obvious looking patch, and we'll see from there 
on?

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223995 — Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due to a kernel NULL pointer dereference)

On Mon, Sep 14, 2015 at 11:35 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Peter Zijlstra <peterz@infradead.org> wrote:
>
>> > I invite you to join the discussion at LLVMLinux... As I know... "YES, you
>> > can." Linux x86/x86_64 (assembler) Kung-Fu. ( I admit I have not these skillz.
>> > )
>>
>> Its a matter of time for me; I simply do not have enough time as it is so I have
>> to make choices.
>
> We are also willing to apply clean, sensible patches.
>
> Alas that collection of llvm patches quoted in this thread:
>
>   30 files changed, 188 insertions(+), 161 deletions(-)
>
> had quite a few objectionable hacks in them.
>

AFAICS LLVMLinux is still a work-in-progress project.

Three patches are labeled with "DO-NOT-UPSTREAM"...

      DO-NOT-UPSTREAM scsi, osd, LLVMLinux: Remove __weak attribute
      WORKAROUND DO-NOT-UPSTREAM x86, boot: Work around clang PR18415.
      DO-NOT-UPSTREAM xen, LLVMLinux: Remove VLAIS from xen mmu

I cannot say much to the other patches - what status they have -
"reported to BTS and have no feedback" or "still discussed" or
whatever.

Some bug-reports are very old - especially in the LLLVM and CLANG BTS.

Can you be concrete on the patches which have in your eyes "a few
objectionable hacks in"?

From my side... How can the correbolation be improved...?

Linux kernel development <-> LLVMLinux development <-> LLVM/CLANG development

BTW, LLVMLinux is a project hosted at Linux Foundation.

I also remember the interview with Linus and c't magazine (German, I
bought this edition) where he talks about compiler and especially
using LLVM for compiling a Linux-kernel.

If you look at the git-logs, there are people found bugs using
LLVM/CLANG and fixed them.
Personally, I like the "verbose" output of LLVM/CLANG more than GCC v4.9.
I did not try any GCC v5.x.

Thanks.

- Sedat -

[1] http://www.heise.de/ct/ausgabe/2014-25-Linus-Torvalds-im-Interview-2449660.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223888 — Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due to a kernel NULL pointer dereference)

On Mon, Sep 14, 2015 at 9:12 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Sun, Sep 13, 2015 at 04:33:39AM +0200, Sedat Dilek wrote:
>> > It looks like an inline-optimization bug in CLANG when the compiler's
>> > optimization-level is higher than -O2.
>
>> > [1] http://lists.linuxfoundation.org/pipermail/llvmlinux/2015-September/001355.html
>>
>> After some discussion on #llvm it turned out to be a known issue in LLVMLinux!
>>
>> Unfortunately, an existing patch [1] got archived which is still
>> required to build x86_64 correctly.
>
>> [1] http://git.linuxfoundation.org/?p=llvmlinux.git;a=blob_plain;f=arch/x86_64/patches/ARCHIVE/0029-Fix-ARCH_HWEIGHT-for-compilation-with-clang.patch;hb=HEAD
>
> As long as LLVM cannot do things like that and requires full function
> calls I cannot see it being a sensible compiler to use from a
> performance POV.
>
> There's a fairly large difference between an inline POPCNT instruction
> and a full out-of-line function call.
>
> /me goes back to ignoring LLVM for the time being.

Can you give an example or describe a test-case to check the performance?

I have here diverse Linux v4.2 kernels (all have the same kernel-config)...

[ llvmlinux-patched ]

#1: Compiled with CLANG v3.7 from a self-built llvm-toolchain v3.7.0
#2: Compiled with GCC v4.9

[ unpatched ]

#3: Compiled with GCC v4.9

Can you also comment on the effects of CONFIG_CC_OPTIMIZE_FOR_SIZE in
case of performance?
It is only to reduce binary size or does it also do some "speed" optimization?

Thanks in advance.

- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1224380 — Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due to a kernel NULL pointer dereference)

[Multipart message — attachments visible in raw view] — view raw

On 2015-09-14 03:49, Sedat Dilek wrote:
> On Mon, Sep 14, 2015 at 9:12 AM, Peter Zijlstra <peterz@infradead.org> wrote:
>> On Sun, Sep 13, 2015 at 04:33:39AM +0200, Sedat Dilek wrote:
>>>> It looks like an inline-optimization bug in CLANG when the compiler's
>>>> optimization-level is higher than -O2.
>>
>>>> [1] http://lists.linuxfoundation.org/pipermail/llvmlinux/2015-September/001355.html
>>>
>>> After some discussion on #llvm it turned out to be a known issue in LLVMLinux!
>>>
>>> Unfortunately, an existing patch [1] got archived which is still
>>> required to build x86_64 correctly.
>>
>>> [1] http://git.linuxfoundation.org/?p=llvmlinux.git;a=blob_plain;f=arch/x86_64/patches/ARCHIVE/0029-Fix-ARCH_HWEIGHT-for-compilation-with-clang.patch;hb=HEAD
>>
>> As long as LLVM cannot do things like that and requires full function
>> calls I cannot see it being a sensible compiler to use from a
>> performance POV.
>>
>> There's a fairly large difference between an inline POPCNT instruction
>> and a full out-of-line function call.
>>
>> /me goes back to ignoring LLVM for the time being.
>
> Can you give an example or describe a test-case to check the performance?
>
> I have here diverse Linux v4.2 kernels (all have the same kernel-config)...
>
> [ llvmlinux-patched ]
>
> #1: Compiled with CLANG v3.7 from a self-built llvm-toolchain v3.7.0
> #2: Compiled with GCC v4.9
>
> [ unpatched ]
>
> #3: Compiled with GCC v4.9
>
> Can you also comment on the effects of CONFIG_CC_OPTIMIZE_FOR_SIZE in
> case of performance?
> It is only to reduce binary size or does it also do some "speed" optimization?

I can comment at least a little about the -Os aspect (although not I'm 
no expert on this in particular).  In general, for _most_ use cases, a 
kernel compiled with CONFIG_CC_OPTIMIZE_FOR_SIZE will run slower than 
one compiled without it.  On rare occasion though, it may actually run 
faster, the only cases I've seen where this happens are specialized uses 
that are very memory pressure dependent and run almost entirely in 
userspace with almost no syscalls (for example math related stuff 
operating on _very, very big_ (as in, >1 trillion elements) 
multidimensional matrices, with complex memory constraints), and even 
then it's usually a miniscule improvement in performance (generally less 
than 1%, which can of course be significant depending on how long it 
takes before the improvement).

[toc] | [prev] | [next] | [standalone]

#1224393

On Mon, 14 Sep 2015, Austin S Hemmelgarn wrote:

> I can comment at least a little about the -Os aspect (although not I'm no
> expert on this in particular).  In general, for _most_ use cases, a kernel
> compiled with CONFIG_CC_OPTIMIZE_FOR_SIZE will run slower than one compiled
> without it.  On rare occasion though, it may actually run faster, the only
> cases I've seen where this happens are specialized uses that are very memory
> pressure dependent and run almost entirely in userspace with almost no
> syscalls (for example math related stuff operating on _very, very big_ (as in,
> >1 trillion elements) multidimensional matrices, with complex memory
> constraints), and even then it's usually a miniscule improvement in
> performance (generally less than 1%, which can of course be significant
> depending on how long it takes before the improvement).

Cache footprint depends on size which has a significant impact on
performance. In our experience the kernel (and any other code) is
generally faster if optimized for size.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1224401 — Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due to a kernel NULL pointer dereference)

[Multipart message — attachments visible in raw view] — view raw

On 2015-09-14 14:27, Christoph Lameter wrote:
> On Mon, 14 Sep 2015, Austin S Hemmelgarn wrote:
>
>> I can comment at least a little about the -Os aspect (although not I'm no
>> expert on this in particular).  In general, for _most_ use cases, a
>> kernel
>> compiled with CONFIG_CC_OPTIMIZE_FOR_SIZE will run slower than one
>> compiled
>> without it.  On rare occasion though, it may actually run faster, the
>> only
>> cases I've seen where this happens are specialized uses that are very
>> memory
>> pressure dependent and run almost entirely in userspace with almost no
>> syscalls (for example math related stuff operating on _very, very big_
>> (as in,
>> >1 trillion elements) multidimensional matrices, with complex memory
>> constraints), and even then it's usually a miniscule improvement in
>> performance (generally less than 1%, which can of course be significant
>> depending on how long it takes before the improvement).
>
> Cache footprint depends on size which has a significant impact on
> performance. In our experience the kernel (and any other code) is
> generally faster if optimized for size.
>
Ah, yes, there is that too (like I tried to say, and messed up my 
grammar in doing so, I'm no expert), although on processors that 
actually have a reasonable amount of cache, this is not usually 
something most people would notice without a benchmark except on a very 
slow processor (HPC workloads and gamers notwithstanding of course).

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web