Memory optimization on 378.56_2

[Rocky Hinson]

Hi,

I'm having an issue verifying the memory optimization change in 378.56_2. It's related to the drop_caches setting. The default value (from "nvram get drop_caches") returns 1. Supposedly to set this value to 0, I would run "nvram set drop_caches=0" and reboot, as mentioned here:

People overreact about the strangest things. Unused ram is wasted ram.

Connect via ssh, login, then enter "nvram set drop_caches=0 (enter), nvram commit", reboot.

While this process does in fact change the setting ("nvram get drop_caches" returns 0 after reboot), it does not affect the value of /proc/sys/vm/drop_caches, which is the value that really needs to be updated. The actual /proc/sys/vm/drop_caches value is always 1 on reboot, regardless of what "nvram get" returns.

Here's the actual Github commit..

Make cache drop user-configurable (defaults to enabled, to match OEM FW)

I think the issue is that f_write_string( ) always writes "1" to /proc/sys/vm/drop_caches. Should it instead query the value with nvram_get_int( ) and then write that value?

 

[Puppa]

The nvram setting and the value in proc are two different things. If your nvram is set, you have the optimization turned on. You should see an increase in the reported RAM use after you activated it.

Sent from my SM-N910V using Tapatalk

 

[RMerlin]

The value that can be read from the proc interface is simply what was the last value written to it. It does not report the firmware's behaviour in any way. The flush only occurs whenever you write to that interface.

 

[Rocky Hinson]

I had expected the proc value to be 0 when I disabled the optimization. I see now it's also written to during system init ..via force_free_caches( ).. which is why 'cat /proc/sys/vm/drop_caches' returns 1 upon reboot. Thanks for the clarification.