Hi,
On 1/25/25 1:00 PM, Stafford Horne wrote:
On Thu, Jan 23, 2025 at 12:25:59AM +0530, Sahil Siddiq wrote:
[...]
Got it. I did find this list in the online documentation [1] but I couldn't find
the cacheinfo task listed there.
Right, not all features have config flags that are documented.
Understood. Do you know how one finds these flags? I wasn't able
to find much related to cpu or caches in arch/openrisc/Kconfig [1].
I did find the usage of ARCH_HAS_CPU_CACHE_ALIASING in
include/linux/cacheinfo.h [2]. I am not sure if this is relevant.
Not all features are enabled using ARCH_ flags. The cacheinfo apis are always
enabled and compiled, even for or1k now. But if we look, we see the default
implementation is defined with __weak symbols:
drivers/base/cacheinfo.c
include/linux/cacheinfo.h
int __weak init_cache_level(unsigned int cpu)
{
return -ENOENT;
}
int __weak populate_cache_leaves(unsigned int cpu)
{
return -ENOENT;
}
Got it, this makes sense now.
In order for us to add support I think all we will need to do is define these
functions under arch/openrisc.
We can look to cpuinfo_or1k for how in openrisc we can pull cache details from
the UPR registers in (we can maybe just get the info from the cpuinfo_or1k
structure):
arch/openrisc/kernel/setup.c
You can read about the background of the cacheinfo work and motivations in the
original patch series:
https://lore.kernel.org/all/[email protected]/
Thank you for the link. I'll go through this patch series. I am beginning
to get an idea of how this has been implemented in other architectures as
well.
On 1/25/25 4:23 PM, Stafford Horne wrote:
Hi Sahil,
Also please check these comments [0] from Sudeep Holla and Stefan Kristiansson.
>> 14/03/17 13:11, Stefan Kristiansson wrote:
>>> On Tue, Mar 14, 2017 at 12:08:33PM +0000, Sudeep Holla wrote:
>>>> On Tue, Feb 21, 2017 at 7:11 PM, Stafford Horne <[email protected]>
wrote:
>>>>> From: Stefan Kristiansson <[email protected]>
>>>>>
>>>>> Motivation for this is to be able to print the way information
>>>>> properly in print_cpuinfo(), instead of hardcoding it to one.
>>>>>
>>>>
>>>> Any particular reason not to use generic cacheinfo sysfs
infrastructure ?
>>>>
>>>
>>> No reason as far as I can see, the creation of this patch predates the
>>> generic cacheinfo sysfs infrastructure.
>>>
>>> The patch itself doesn't add cache information to cpuinfo though,
>>> only corrects a bug in the information that is already there.
>>>
>>> We should look into exposing the info in the generic cache info sysfs
>>> and potentially removing the information from cpuinfo.
-Stafford
[0[] https://lkml.org/lkml/2017/3/14/639
Sure. I'll go through the aforementioned patch series and comments.
[...]
I have set up a fairly basic environment. I built both QEMU and
openrisc-linux from the master branch. I used a prebuilt compiler
toolchain to build openrisc-linux and busybox, and manually
created an initramfs image. I used the default configuration
options to build linux.
The userspace environment only has utilities that are provided
by busybox. Only the following filesystems have been mounted -
rootfs, devtmpfs, sys, proc and tmpfs.
I tried to understand the workings of some of the scripts in
or1k-utils. There were a few things that I didn't understand
and I'll need some more time to wrap my head around them. I
don't think this should hinder the cacheinfo task though.
Is there anything else that I'll need to set up in the environment
before progressing?
I think its a good start. As long as /sys is available in your environment
it should be enough for you to test your changes.
Understood.
I don't see any cache-related info in /sys. Based on what I have
understood, it'll be possible to fetch these details once cacheinfo
is supported.
On my x86 machine I see:
$ tree /sys/devices/system/cpu/cpu0/cache/
/sys/devices/system/cpu/cpu0/cache/
├── index0
│ ├── coherency_line_size
│ ├── id
│ ├── level
│ ├── number_of_sets
│ ├── physical_line_partition
│ ├── shared_cpu_list
On or1k I only see (no cache info yet):
$ tree /sys/devices/system/cpu/cpu0/
/sys/devices/system/cpu/cpu0/
|-- of_node -> ../../../../firmware/devicetree/base/cpus/cpu@0
|-- subsystem -> ../../../../bus/cpu
|-- topology
| |-- core_cpus
| |-- core_cpus_list
| |-- core_id
| |-- core_siblings
| |-- core_siblings_list
| |-- package_cpus
| |-- package_cpus_list
| |-- physical_package_id
| |-- thread_siblings
| `-- thread_siblings_list
`-- uevent
But we do have some cache info available via cpuinfo:
$ cat /proc/cpuinfo | head -n16
processor : 0
cpu : OpenRISC-13
revision : 8
frequency : 20000000
dcache size : 256 bytes
dcache block size : 16 bytes
dcache ways : 1
icache size : 32 bytes
icache block size : 16 bytes
icache ways : 2
immu : 128 entries, 1 ways
dmmu : 128 entries, 1 ways
bogomips : 40.00
features : orbis32 orfpx32
Ah yes. I missed this. I see this in my environment as well.
At the momoment, I am also thinking of what to work on next for OpenRISC, there
is:
- kexec
- jump_label
- kprobes
- perf_events
- ftrace
Is the virtio task [2] also still a part of the roadmap? I can't find that
either
in the TODO list.
The virtio task is still possible but will be more advanced and may need some
architecture changes to support hypervisors.
Got it.
I am slowly working on kexec support right now.
Understood. Once cacheinfo is implemented, I would like to pick one of the
other tasks as well :)
Thanks,
Sahil
