[Kernel][10.05.2024][Android 14.0.0]Kirisakura 2.2.4_Raviantah for Pixel 6/Pro aka "RAVIOLE" (2024)

Freak07 said:

Thanks for the report. I´ll try to clear it up a bit for you.
I don´t know what other kernels do exactly, as I´m usually not following them very closely, but I can answer for my project.

The cores not maxed out constantly for two minutes directly after restart are by design. What you´re seeing is the PMU limiter restricting the frequencies, because the threshold for requesting more performance is not crossed. This prevents a lot of additional heat. Especially the higher frequencies are "inefficient" in more than one way. There´s a higher than linear increase in heat/powerdraw vs performance increase.
The PMU limiter feature is described in detail following this link. I suggest to give a good read, because this is vital background information for everything I´m trying to explain below.
Please note: The PMU limiter does not operate in this manner on the stock kernel.

If you use a CPU-Frequency overlay you will see higher frequencies are being used during app launches, like in the screenrecord below. Notice that this is not a real-time representation of what´s actually happening on the phone. So you can´t draw any definitive conclusions about it. Frequencies change much much faster than those overlays, or the live freq view in EXKM can show to a user. (Many many times in a 10th of a second) But to explain this topic in a simplified manner is possible with it.

New video by freak 07

photos.app.goo.gl

For the explanation below keep the limits of the PMU limiter based on different conditions in mind. And also keep in mind that PMU limiter doesn't hard limit, it just limits higher freqs until a certain threshold of requested performance is crossed
You'll see at first I start devcheck app. The app is still in memory, that's why the cores don't max out on the overlay. (that doesn´t mean that max freq is not used for the fraction of a second, just the overlay won´t catch it) There's not much to load on the page that's being opened either on the app. Going back to the start page of devcheck, there are more elements in the UI, hence bigger freq bump.

Launching CPU benchmark app and running it, you'll see big cores are maxing out when max performance is requested by running the workload of this benchmark. During this benchmark the workload gets scheduled mostly to the big cores (you can't see this with apps or overlays just by tracing the scheduler). That's why you see max cores max out crossing the PMU limiter threshold easily.

EXKM app is cold launched. I force closed the app before the screen recording so it needs to be loaded completely from scratch. You'll see max freqs are reached, PMU limit for app launches (2,4ghz for big cores) is crossed during the launch to load the app as fast as possible.

Now here's the cpufreq distribution taken from exkm on my end since flashing yesterday evening.

3 new items by freak 07

photos.app.goo.gl

All frequencies are being utilized on all cores. But you can also see the PMU limiter is doing its job. Let's take the efficient cluster with the little cores as example.
You'll see the maxfreq of 1.8ghz for little cores is utilized most of all higher freq steps (1.19GHZ and above). But you can also see the PMU limiter is kicking in, as 1.19GHZ and 1.4GHZ are just after that.

All of this is expected. This works completely different from stock and it's expected that you will be able to tell differences.

Now how does that tie in with other system processes?
The AK3 module you´re seeing in magisk manager after flashing this kernel allows to replace certain parts of those system processes, so that those work with the changes done on the kernel side. The kernel isn't a unit that stands just for it alone.

Example: The PMU limiting itself is done via kernel. But the different conditions on which PMU limiting is triggered (launching apps, 120fps, scrolling, display idle, screen content moving, etc, etc) are detected and handled not by the kernel side, because the system just has more information what's currently happening.
Same for the thresholds of the PMU limiting. The system detects what is happening on your phone like scrolling, screen content static, screen content moving, app launching etc, and different thresholds for the PMU limiting are set.
This information is fed to the kernel via the powerhal, so it can do its job.

You'll notice a difference in freq distribution on this kernel to stock, as it's a deliberate change.
Read the linked posts and I think you'll understand. I'm here for questions.
But keep in mind. All those end-user focused UI tools like CPU freq overlays, live freqs in exkm don't reflect what's actually happening, just give a rough idea. There's a lot of room for misinterpretation.

Click to expand...

Click to collapse

I have used this kernel on this device and many others. Like the pixel 3 xl.. I stopped using kernels once AK3 was introduced. Problems across many devices. I tried helping the issue before, but can't help someone who thinks OnePlus is the defacto on Android. I used a few different UI apps to all see the same frequency issues. Now it's been a day since I updated, and I can see without a restart since yesterday, all my frequencies have been used at one time or another. Not real time but total calculated time via UI app. Dev check to be specific. I read your post and the last frequency set you list is the only one my phone ever used.. max frequencies would be stuck at that set you list and lowest possible frequency would go to variable.. battery drop whenever using the phone with games. And hard..like 10% in 10 minutes. Maybe get a total of 2 hours screen time total all day. I am at 2 hours screen time right now and have 83% battery. That is great for me. The past month has been charge the phone by lunch if I use anything that needed high power, my theory, it didn't get to use the high power therefore it would over use battery to compensate for not being able to run higher frequencies. Also lag issues once in awhile watching movies, buffering on perfect cell reception. Most of the time the kernel worked great. But, I would get once in awhile a freeze when opening the phone(not being able to go into higher frequencies). This was never an issue before on stock and isn't now. OnePlus isn't android. AK3 dev uses OnePlus as his defacto. He should use AOSP or a Pixel as defacto. That is the biggest issue with AK3.