Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1190638 - sysconf (glibc) for AArch64 does not report cache line size (LEVEL1_DCACHE_LINESIZE)
Summary: sysconf (glibc) for AArch64 does not report cache line size (LEVEL1_DCACHE_LI...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: aarch64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: glibc team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ARMTracker
TreeView+ depends on / blocked
 
Reported: 2015-02-09 10:24 UTC by David Abdurachmanov
Modified: 2017-10-31 15:28 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-10-31 15:28:06 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description David Abdurachmanov 2015-02-09 10:24:53 UTC
Description of problem:

On Fedora 21 GA for AArch64 sysconf/getconf does not provide cache line size information.

[root@localhost ~]# getconf LEVEL1_DCACHE_LINESIZE
0

NOTE: This depends on vendor, APM X-Gene 1 should have 64 bytes, while Cavium ThunderX 128 bytes.

Version-Release number of selected component (if applicable):

2.20

Seems not implemented in trunk, up to:

commit 28b067571e98d3047da7020014502ff2391703be
Author: Samuel Thibault <samuel.thibault>
Date:   Sun Feb 8 18:46:00 2015 +0100

How reproducible:

Steps to Reproduce:

Execute: getconf LEVEL1_DCACHE_LINESIZE

Actual results:

0

Expected results:

Should have printed 64 on APM X-Gene 1 for dCache line size.

Additional info:

We might need to implement something like `sysdeps/x86_64/cacheinfo.c`, which acquires cache information for x86_64 processors. Cache information is available in special registers on AArch64 (EL0 and EL1). E.g., cache line information is available on EL0:

#include <stdio.h>

int main(void) {
 unsigned int cache_info = 0;
 unsigned int icache_lsize;
 unsigned int dcache_lsize;
 asm volatile ("mrs\t%0, ctr_el0":"=r" (cache_info));
 icache_lsize = 4 << (cache_info & 0xF);
 dcache_lsize = 4 << ((cache_info >> 16) & 0xF);

 printf("iCache line size: %d, dCache line size: %d\n", icache_lsize, dcache_lsize);

 return 0;
}

$ ./a.out
iCache line size: 64, dCache line size: 64

Cache size information is available in CCSIDR_EL1 (NOTE: EL1). It looks like L1 and L2 cache sizes and other information is only for EL1 and above. Yet cache information registers are RO in all modes.

Comment 1 Jaroslav Reznik 2015-03-03 16:51:40 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Comment 2 Jan Kurik 2016-02-24 13:21:00 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

Comment 3 Peter Robinson 2016-08-31 12:10:14 UTC
Actually this reports zero on ARMv7/aarch64/ppc64/ppc64le although it reports correctly on s390x

Comment 4 Peter Robinson 2016-11-20 13:27:59 UTC
David can you confirm if this is still the case for F-25+

Comment 5 Carlos O'Donell 2017-10-31 15:28:06 UTC
(In reply to Peter Robinson from comment #3)
> Actually this reports zero on ARMv7/aarch64/ppc64/ppc64le although it
> reports correctly on s390x

In upstream only x86_64, s390, and pp64/ppc64le have support for detection of hardware cache line sizes. ARM has not implemented this yet, so all of these routines return 0 for cache line sizes (meaning the size is not known). A return of -1 would indicate no limit, and that's not correct to return.


Note You need to log in before you can comment on or make changes to this bug.