Why is the L2 cache disabled by default on Raspbian Jessie?

Question

When I ran vcgencmd get_config int to check if max_usb_current was applied, I noticed a peculiar line on the output:

pi@srv0 ~ $ vcgencmd get_config int

arm_freq=1000
config_hdmi_boost=5
core_freq=500
disable_commandline_tags=2
disable_l2cache=1
emmc_pll_core=1
force_eeprom_read=1
force_pwm_open=1
framebuffer_ignore_alpha=1
framebuffer_swap=1
hdmi_force_cec_address=65535
max_usb_current=1
over_voltage=2
over_voltage_avs=0x1b774
pause_burst_frames=1
program_serial_random=1
sdram_freq=500
temp_limit=85

I noticed the line that says disable_l2cache=1.

I presume the L2 cache was disabled by default (I could be wrong, it might be because of the overclock). Why is this so? Will enabling the L2 cache have good and/or bad effects? What would happen if I did turn it on in /boot/config.txt?

It's a headless setup, and I'm using it as a turnkey server.

Here's my config.txt in case anyone is curious:

pi@srv0 ~ $ cat /boot/config.txt

# For more options and information see
# http://www.raspberrypi.org/documentation/configuration/config-txt.md
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
arm_freq=1000

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi

# Additional overlays and parameters are documented /boot/overlays/README

core_freq=500
sdram_freq=500
over_voltage=2
gpu_mem=64
dtparam=i2c_arm=on

max_usb_current=1

Answer 1

On the Pi1 there was a L2 cache which was primerally intended for use by the VPU but could also optionally be used by the arm core. IIRC in the intial firmware the arm didn't use this cache but with later firmware it used it by default.

On the Pi2 the arm cluster has it's own l2 cache so there is no reason for it to use the L2 cache intended for the GPU.

If you are using a pi2 I suspect that the "disable_l2cache=1" you are seeing really means "the arm cores are not using the cache intended for the videocore because it has it's own l2 cache".

Answer 2

I get the same thing (disable_l2cache=1) without overclocking on a Pi 2 running a stock 4.1.9-v7+ kernel and the latest firmware update. The distro is Fedora 21, but I do not think the distro will make any difference except to the extent of the /boot/config.txt settings.

I presume the L2 cache was disabled by default

According to this, it shouldn't be, but I notice some of the other defaults there might be inaccurate, e.g.:

arm_freq_min Minimum value of arm_freq used for dynamic frequency clocking. The default value is 700.

While there was no explicit setting, in /sys/devices/system/cpu/cpu0/cpu_freq, the cpuinfo_min_freq is 600 and that's what the actual cpuinfo_cur_freq was (the pi is idle). Perhaps this has to do with scaling_available_frequencies being 600 and 900.

Why is this so?

As a complete guesses, it's to do with the Pi 1 (A/B/+). According to this, the single core BCM2835's L2 cache was shared with the video core. This might mean there would be an advantage to disabling it. Also, looking through here and wikipedia it sounds like the L2 cache on the ARM Cortex-A7 (such as the Pi 2's BCM2836) is better integrated into the hardware than the software driven L2 caching on the ARM1176 (the Pi 1's BCM2835).

Will enabling the L2 cache have good and/or bad effects?

I doubt it would have bad effects; looking at all the tweaking and benchmarking going on here, where l2disable is not mentioned but the other mem/cpu settings are (implying it was not set), it's probably better that way. Based on his assertion that "certain divisor relationships between CPU clock and core (L2 cache) clock" [core_freq] "(such as 2:1) seem to enhance stability and performance" (the default is 250), I set:

disable_l2cache=0
arm_freq_min=600
core_freq_min=300
core_freq=450

Which vcgencmd reports correctly (actually what it does now is not show a value for disable_l2cache). It did not explode or anything. There is no mention of warranty bit issues with these parameters (for that you apparently have to turn off dynamic scaling).

So I guess you could come up with some benchmarks and decide about this yourself. I tried compiling some stuff. Didn't make it noticeably faster or anything ;)