Thanks, Gabriel, and Damjan. It appears to me that the glibc getconf program is using its own mechanisms for determining cache line size, rather than using the information that the kernel has. That is my reading of the glibc code, so I do not believe Damjan you will see any different behavior with a newer kernel. Possibly you would see differences in /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size (or some such path). Maybe the correct information is there, with old and/or new kernel? Anyway, I think we know not to trust getconf for the cache line size in ARM; at the present time. I suppose configure.ac could be again changed, to use the kernel info; on the other hand, "if it ain't broke, don't fix it."
Burt On Mon, Feb 13, 2017 at 11:17 AM, Damjan Marion (damarion) < damar...@cisco.com> wrote: > > On 13 Feb 2017, at 17:11, Gabriel Ganne <gabriel.ga...@enea.com> wrote: > > Hi Burt, > > Thank you for your input. > I pushed a new version of my commit (https://gerrit.fd.io/r/#/c/4576/) > where I tried to do things more clearly. > > I had a look here https://github.com/torvalds/linux/blob/master/ > arch/arm64/kernel/cacheinfo.c and it seems that on arm64, recent kernels > should be able return a correct value. Which means that some day, they will. > Old ones will fallback to 64 Bytes. > > Maybe someone who has a thunder platform can try it in order to see what > getconf returns him. > > > I tried on my ThunderX system, and it returns 0, but kernel which I’m > running is old (one from SDK). > I am not able to run standard ubuntu kernel for arm64 on that system, it > just freezes very early in the boot process. > As ThunderX is listed as certified [1], I guess i’m doing something wrong…. > > [1] https://certification.ubuntu.com/hardware/201609-25111/ >
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
