[TAMA][APOLLO] UI performance degradation (aosp, lineage)

[leeoniya]

Platform: TAMA Device: XZ2 Compact Kernel version: 4.14 Android version: 10 Software binaries version: 8

Previously working on

stock (H8314_Customized US_1313-0031_52.1.A.0.672_R7C)

Description

not sure if this report belongs here as this may be an AOSP issue, but @MartinX3's XZ2 with the same setup apparently has no UI lag issues, so i was directed here.

this is a continuation of multiple attempts to isolate the cause without success.

device:

• TAMA/Apollo H8314 w/unlocked bootloader
• no sim card inserted
• no sd card inserted

the lag-free (stock) route:

1. using newflasher_v20 flashed H8314_Customized US_1313-0031_52.1.A.0.672_R7C (excluding *.ta files, answering n to all prompts)
2. unplug/power off
3. booted into fastboot via vol-up + replug
4. fastboot flash oem_a SW_binaries_for_Xperia_Android_10.0.7.1_r1_v8a_tama.img
5. fastboot flash oem_b SW_binaries_for_Xperia_Android_10.0.7.1_r1_v8a_tama.img
6. unplug & boot via power btn
7. booted into system
   • went through wifi init & "installing updates"
   • skipped google acct setup
   • declined to install additional apps
   • turned off location services
   • skipped pin setup
8. played around with UI, pulled up app drawer, swiped between home screens, scrolled settings menu. no visible lag.
9. enabled developer options
10. toggled "Show view updates" under "Hardware accelerated rendering". scrolled around and interacted with items & screen which flashed red.
11. turned off "Show view updates"
12. toggled "Show surface updates" under "Drawing". scrolled around and interacted with items & screen which flashed magenta.
13. plugged phone into machine
14. adb logcat -b all > logcat_stock.txt (attached)

the lagging (aosp/lineage) route:

(continuing from all the stock steps above)

1. adb reboot recovery (fails & boots back into system)
2. adb reboot bootloader (gets me into fastboot)
3. fastboot boot 2020-06-14_21-07-37_twrp_apollo.img (using @MartinX3 stock twrp build)
4. [Advanced] => [ADB Sideload]
5. adb sideload aosp-10.0-20200606_aosp_h8314.zip (using @MartinX3 aosp build)
6. message says to reboot recovery to switch to updated slot
7. [Reboot] => [Recovery]
8. in [aosp? blue text] recovery, [Reboot to bootloader]
9. fastboot flash oem_a SW_binaries_for_Xperia_Android_10.0.7.1_r1_v8a_tama.img
10. fastboot flash oem_b SW_binaries_for_Xperia_Android_10.0.7.1_r1_v8a_tama.img
11. fastboot reboot
12. Sony logo, boot loops once or twice
13. lands in orange/red/blue recovery shown here. (might be caused by a TWRP data wiping bug: https://forum.xda-developers.com/showpost.php?p=82873689&postcount=445)
14. [Factory data reset] > [Factory data reset] (auto-reboots after format /data)
15. boots into aosp
16. played around with UI, pulled up app drawer, swiped between home screens, scrolled settings menu. initial interactions are pretty smooth, but degrade quickly as if there's no HW acceleration or UI is fighting the OS compositor. scrolling and menu transitions happen at much reduced framerate. scrolling setting menu lags touch location by by hundreds of milliseconds.
17. enabled developer options
18. toggled "Show view updates" under "Hardware accelerated rendering". scrolled around and interacted with items & screen which flashed red.
19. turned off "Show view updates"
20. toggled "Show surface updates" under "Drawing". scrolled around and interacted with items & screen which flashed magenta.
21. adb logcat -b all > logcat_aosp.txt (attached)

stock-aosp-logs.zip

another observation with @MartinX3's lineage 17.1 is that the stock browser's webpage scrolling performance is smooth and does not degrade. this seems to only affect the OS ui bits.

hopefully something obvious, thanks!

[leeoniya]

someone also reported UI lag issues in the same thread:

https://forum.xda-developers.com/showpost.php?p=82866607&postcount=431

[ix5]

First off:

RILD : dlopen failed: dlopen failed: library "/odm/lib64/libril-qc-qmi-1.so" not found

Radio is crashing all the time and servicemanager is trying to re-up it. Looks like a certain someone forgot something.

---

Performance degradation over time can happen for a multitude of reasons, chiefly memory leaks.

At startup, Android is doing lots of things and needs a bit of time to settle and optimize. Stock is doing the smart thing by DEX-preopting and pinning the pre-opted dex/jar files into memory, while SOD enables pre-opting only for system server.

Another reason is that our PowerHAL isn't doing what it's supposed to do. Touch boost and other niceties aren't being recognized because of missing hookup of hints to sysfs nodes, that's why you're seeing stuff like RQBalance-PowerHAL-Hints: Error opening <...>.

All our performance, buffer, whathaveyou configs could also use an overhaul. I think we've yet to switch to vulkan rendering... Also, some users report that setting use_buffer_age=true reduces some jank.

To everyone on the team, the whole "Evaluating performance" section from Elgoog's docs is quite enlightening.

Maybe calvin and lazerlord could give us a hand as well.

[leeoniya]

I think we've yet to switch to vulkan rendering

maybe not too relevant, but my daily driver right now is a Z5 Compact with Lineage 14.1 and it's been jank-free since as long as i can remember. pretty sure this was long before vulkan was even a thing (especially on android) and it doesn't seem to need it to work smoothly on a much less capable cpu/gpu/ram (though the screen res is smaller, too). 🤷

[MarijnS95]

Vulkan is definitely not a requirement but will provide that tiny extra bit of CPU headroom for broken ROMs looping to start/retrieve whatever service, with crashes inbetween. I have yet to send an AOSP patch upstream to make it work properly, though. While there are improvements to be made to SODP like @ix5 pointed out there's nothing we can objectively help out with until this ROM is fixed.

Finally, the "previously working on" section is intended (though not explicitly stated) to cover SODP; we're pretty much assuming things work as normal on a stock image... In this instance those RIL errors should start appearing from v8 blobs onwards. If they are in any way related (unlikely) we would like to know how previous iterations (if tried by the user) fared.

[MartinX3]

@leeoniya the oem file not found error should happen, because you didn't use OEMv7 for the AOSP build. But that shouldn't be the reason for the sluggish UI, since the same happen with the OEMv8 ROM build you tested.

And the stock route doesn't need the OEM image from SODP :P

I see many times E dsi-ctrl: [dsi_ctrl_handle_error_status] tx timeout error: 0x40 These happening on akari as well, but there the UI freezes completely sometimes for a short time. Especially if I use a videochat.

[leeoniya]

@MartinX3, new log for aosp-10.0-20200620_aosp_h8314.zip:

logcat_aosp_20200620.zip

[leeoniya]

OEMv9 seems to be out now :)

SW_binaries_for_Xperia_Android_10.0.7.1_r1_v9b_tama.zip

does it happen to address this issue, by chance?

[leeoniya]

sadly, no improvement with 9c.

tx timeout error: 0x40 is still in the logs:

logcat_lineage-2020-07-13.zip

[rinigus]

Just to chip in as I had tested a bit AOSP10 ROMs. Looks like Lineage and SODP10 are both affected by lags, as mentioned above. On PE, while getting the same errors in logs, I did not perceive such slow down. Could be due to limited testing (Android is not really my target in it), but could be something else than tx errors leading to perceivable lag in the interactions.

[MarijnS95]

@rinigus that's quite likely due to PE using skiavk which makes UI rendering (shapes, text) much more efficient.

Unfortunately we have reverted it because Vulkan support in AOSP isn't perfect yet.

[leeoniya]

https://github.com/sonyxperiadev/bug_tracker/issues/603#issuecomment-646897477 but my Z5C runs without UI lag on LoS 14.1 without Vulkan. (scratching head).

[MarijnS95]

@leeoniya In case you want me to repeat myself:

There's something else going on with the device. Broken services, or a more likely hardware misconfiguration that all off Tama is suffering from. Vulkan decreases overhead, more-or-less hiding the issue underneath. (More specific: frames complete faster so that there is more time to push them to the display. Afaik one of the buses here is sometimes configured too low, leading to these timeouts and degradation on Apollo, display corruption on Akatsuki).

Bringing up your Z5C again adds nothing to the conversation.

[MartinX3]

If @rinigus tried the SODP based Lineage, it uses skiavk, too. (Which'll get reverted there as well)

[rinigus]

@MartinX3, it was SODP based, indeed. That was your 20200713 build. AOSP build was 20200714 and PE from the same date.

[leeoniya]

@MarijnS95, sorry, but skiavk support being reverted in AOSP, being absent on Z5C, or being present on PE, is clearly not the cause of this issue, but it's being framed (again) as if lack of vulkan is what's going on.

anyways, i hope you guys can figure it out. thanks for your ongoing work!

[MarijnS95]

@leeoniya FWIW you mentioned in your initial report to use "Show view updates", but you're much better off going to Monitoring > Profile HWUI rendering in Developer Settings, and set it to "In adb shell dumpsys gfxinfo". Play around a bit, then pull the output from that command and paste the logs. I'd like to compare them to Akatsuki.

@MarijnS95, sorry, but skiavk support being reverted in AOSP or being present on PE, is clearly not the cause of this issue, but it's being framed (again) as if lack of vulkan is what's going on.

That was merely in response to @rinigus who observed that PE, which is on exactly the same hardware base as LOS or SODP(...), had less jank. Let me quote myself again:

Vulkan is definitely not a requirement but will provide that tiny extra bit of CPU headroom for broken ROMs

[leeoniya]

but you're much better off going to Monitoring > Profile HWUI rendering in Developer Settings, and set it to "In adb shell dumpsys gfxinfo". Play around a bit, then pull the output from that command and paste the logs.

k, i'll try to do that today.

[leeoniya]

hey guys, sorry for the radio silence.

lots of things have changed since July.

LineageOS is now officially supported on Apollo and @MartinX3 has EOL'd his SODP Lineage & AOSP builds.

before flashing the nightly Lineage, i'd like to re-test and give you guys the latest gfxinfo logs, but i have no recent android build besides stock that's compatible with SW_binaries_for_Xperia_Android_10.0.7.1_r1_v11a_tama.img.

any advice?

thanks!

[MartinX3]

hey guys, sorry for the radio silence.

lots of things have changed since July.

LineageOS is now officially supported on Apollo and @MartinX3 has EOL'd his SODP Lineage & AOSP builds.

before flashing the nightly Lineage, i'd like to re-test and give you guys the latest gfxinfo logs, but i have no recent android build besides stock that's compatible with SW_binaries_for_Xperia_Android_10.0.7.1_r1_v11a_tama.img.

any advice?

thanks!

If my SODP LOS isn't compatible anymore, you could look for a newer Pixel Experience Build. My next builds will be Android 11 :)

[leeoniya]

If my SODP LOS isn't compatible anymore, you could look for a newer Pixel Experience Build.

with latest stock (H8314_Customized US_52.1.A.3.74-R7C) and latest binaries (SW_binaries_for_Xperia_Android_10.0.7.1_r1_v11a_tama.img), the kernel is matched to the firmware, right?

if i flash an older SODP LOS over v11a, wouldn't this cause possible issues (even if it technically boots).

[leeoniya]

i repeated all the steps from the first comment with the v11a binaries and stock H8314_Customized US_52.1.A.3.74-R7C, and the last sodp aosp build: aosp-10.0-20200818_aosp_h8314.

(the UI slowdown remains).

logs-gfxinfo.zip

[leeoniya]

there is no UI lag when flashing the 2020-10-16 build of lineage OS plus the v11a binaries, here are the logs:

gfxinfo_los20201016.zip

[MarijnS95]

You are not supposed to flash ODM binaries on stock or stock-based ROMs, the files therein are solely for the Sony Open Device Project. Your device will boot however because this partition contains (last I checked) just some telephony and regional overlays, with all the hardware blobs on vendor instead.

It is pretty clear indeed that AOSP has many dropped frames, whereas LOS has next to none. It looks like you only captured logs at the end, but our log buffer isn't large enough and many lines are missing (chatty : uid=xxxx(yyyy) zzzz expire wwww lines). I'm hoping to see vsync issues or other warnings about late frames in the log.

(Un)fortunately I have never noticed any of these slowdowns on SODP Akatsuki (also Tama platform). Despite Martin's LOS builds using all our HALs there might still be a discrepancy in there somewhere; in order to really take this issue forward we need to validate what happens on plain SODP Apollo.

[leeoniya]

in order to really take this issue forward we need to validate what happens on plain SODP Apollo.

would you be able to give me the steps required to do this (including links to the files/builds)?

i am still very confused about the order in which i need to flash, which things and where it is appropriate vs redundant.

you're saying i don't need to flash the v11a binaries if i'm flashing H8314_Customized US_52.1.A.3.74-R7C (excluding *.ta files) via newflasher_v36? (geeen led, flashmode?)

do i need to flash v11a binaries for official lineage dev builds? before or after?

do i need to flash v11a binaries for SODP builds (both AOSP and Lineage) before or after?

do these binaries "stick"? or do i have to keep re-flashing them every time a sideload or flashmode a rom?

i've heard that you need to boot into the system for it to finish setting up the modem? is this only for stock?

i feel like i'm doing a lot of redundant things without really understanding the proper order and wasting a ton of time :(

[MarijnS95]

would you be able to give me the steps required to do this (including links to the files/builds)?

I don't know if any (up to date) Apollo SODP builds are available. FWIW this is a developer-oriented project providing a base for those interested in building plain AOSP or porting it to their next ROM (https://opendevices.ix5.org/). Your safest bet is to actually sync and build our entire (Android 11 with corresponding 11-v1 blobs) tree, given you have the time and a machine capable of doing so. Otherwise we'll have to depend on other contributors with an Apollo.

do i need to flash v11a binaries for official lineage dev builds? before or after?

"official" Lineage builds are stock builds, and hence don't need ODM which - again - is for SODP (based) ROMs only. Said differently: did their installation guide ask to flash ODM in addition to their package?

do i need to flash v11a binaries for SODP builds (both AOSP and Lineage) before or after?

ODM (v11a binaries) need to be flashed when running SODP or a SODP-based ROM. These only need to be reflashed when:

1. There's an update
2. The partition has been overwritten (ie. using Emma or another flashing tool to take the phone back to stock)

Data in these partitions doesn't magically disappear. No need to re-flash them every time. Likewise, there's no strict flashing order, as long as the image makes it to the device before booting. (otherwise SODP will simply not boot)

do these binaries "stick"? or do i have to keep re-flashing them every time a sideload or flashmode a rom?

Well, I guess I was replying to your message top-to-bottom without reading all questions first. As said above everything on your phone "sticks" unless the flashing tool at hand overwrites a partition. Same story for sideloading if the script mounts and alters a a partition. With all this stock-based ROM magic and flashing tools I wouldn't trust anything though.

i've heard that you need to boot into the system for it to finish setting up the modem? is this only for stock?

That was for SODP, but since we have our own modem flashing support now this is no longer necessary. I don't think there's any other setup on stock that is strictly required before booting into SODP.

[leeoniya]

Your safest bet is to actually sync and build our entire (Android 11 with corresponding 11-v1 blobs) tree, given you have the time and a machine capable of doing so. Otherwise we'll have to depend on other contributors with an Apollo.

i guess @MartinX3 is our only hope. the only other SODP rom is Pixel Experience i guess, but it's bloated with GAPPS and also out of date (no updates since Aug): https://forum.xda-developers.com/xperia-xz2-compact/development/rom-pixel-experience-xperia-xz2-compact-t4054675

there's this which claims SODP Android 11 and much more recent but the thread was closed for unstated reasons: https://forum.xda-developers.com/xperia-xz2/development/rom-aosp-11-t4169671

Said differently: did their installation guide ask to flash ODM in addition to their package?

https://wiki.lineageos.org/devices/xz2c/install

the very first step says Warning: Before following these instructions please ensure that the device is on the latest Android 10 firmware., but i guess that means flash H8314_Customized US_52.1.A.3.74-R7C first, and then just side-load lineage into slot a and/or slot b after fastbooting into a compatible recovery (lineage or twrp).

[MartinX3]

Your safest bet is to actually sync and build our entire (Android 11 with corresponding 11-v1 blobs) tree, given you have the time and a machine capable of doing so. Otherwise we'll have to depend on other contributors with an Apollo.

i guess @MartinX3 is our only hope. the only other SODP rom is Pixel Experience i guess, but it's bloated with GAPPS and also out of date (no updates since Aug): https://forum.xda-developers.com/xperia-xz2-compact/development/rom-pixel-experience-xperia-xz2-compact-t4054675

It's on the todo list :D

there's this which claims SODP Android 11 and much more recent but the thread was closed for unstated reasons: https://forum.xda-developers.com/xperia-xz2/development/rom-aosp-11-t4169671

It got closed because the the thrrad owner wanted you to registrate yourself on his download link and now he doesn't respond anymore to the moderator.

[MarijnS95]

@leeoniya Those PE images are mostly sane, they are maintained by the same guys that bring you SODP.

but it's bloated with GAPPS

Might as well run PE just to see if the issue persists, you can always move on to other ROMs afterwards.

and also out of date (no updates since Aug)

FWIW the post hasn't been updated since Februari... But no need to if the buildserver keeps churning out monthly builds for your device, with the latest SODP patches hot off the press: https://download.pixelexperience.org/h8314

there's this which claims SODP Android 11 and much more recent but the thread was closed for unstated reasons:

I wouldn't trust random compiled images on XDA, that moderator must have closed it for a reason and it looks dated as well. Bluetooth should have long been fixed since the 29th of November. IMO these are just trolls wanting to be the first to release the next Android version on XDA, when in fact all the porting and stability work is done here by our team.

Said differently: did their installation guide ask to flash ODM in addition to their package?

https://wiki.lineageos.org/devices/xz2c/install

the very first step says Warning: Before following these instructions please ensure that the device is on the latest Android 10 firmware., but i guess that means flash H8314_Customized US_52.1.A.3.74-R7C first, and then just side-load lineage into slot a and/or slot b after fastbooting into a compatible recovery (lineage or twrp).

Yeah it is pretty clear that they don't mention anywhere to go to developer.sony.com and download binary ODM image for their device, for reasons mentioned above :grimacing:

[leeoniya]

But no need to if the buildserver keeps churning out monthly builds for your device, with the latest SODP patches hot off the press: https://download.pixelexperience.org/h8314

ok, i'll do that.

It looks like you only captured logs at the end, but our log buffer isn't large enough and many lines are missing (chatty : uid=xxxx(yyyy) zzzz expire wwww lines).

is this something i can adjust/increase prior to running adb shell dumpsys gfxinfo? does logcat -c help?

[MarijnS95]

The logs are not relevant for whatever dumpsys gfxinfo outputs. gfxinfo only gives statistics but it doesn't explain why the statistics are like that... For that I hope to find more info in the logs (if this happens on a sane, clean, recent build).

You can change pruning behaviour with logcat -P followed by the UID or PID but I hardly ever use this. Easier is to just start the logcat pipe (logcat > the_log) before or immediately after (re)boot, it'll start as soon as adb comes up on the device and print anything (old and new) before it is expired.

[AngryGami]

@ix5 I also see a lot of RQBalance-PowerHAL-Hints: Error opening <...> on my devices. Does what you've said mean that I can ignore these errors because they have no impact on device functionality/performance or this mean that these errors do have impact but won't ever be fixed unless Sony do something about that?

[sjllls]

@ix5 I also see a lot of RQBalance-PowerHAL-Hints: Error opening <...> on my devices. Does what you've said mean that I can ignore these errors because they have no impact on device functionality/performance or this mean that these errors do have impact but won't ever be fixed unless Sony do something about that?

@AngryGami Try this. https://github.com/sjllls/device-sony-common/commit/de3b2bbbc33130891263d9e81ea2178a0f6783c4

[MarijnS95]

That error is simply because we never enabled cpuquiet in the kernel. Angelo wanted to fix up some breakage/misconfiguration around it but we are working on higher prio stuff right now. Shouldn't have any effect on stutteriness/slowdown.

[sjllls]

That error is simply because we never enabled cpuquiet in the kernel. Angelo wanted to fix up some breakage/misconfiguration around it but we are working on higher prio stuff right now. Shouldn't have any effect on stutteriness/slowdown.

@MarijnS95 Did you noticed pdx201 get lower CPU performance than normal sdm665 level? I tested on Antutu, got score about 56000, normal level should be 72000.

Maybe because we did some tweaks on sched?

[MartinX3]

That error is simply because we never enabled cpuquiet in the kernel. Angelo wanted to fix up some breakage/misconfiguration around it but we are working on higher prio stuff right now. Shouldn't have any effect on stutteriness/slowdown.

@MarijnS95 Did you noticed pdx201 get lower CPU performance than normal sdm665 level? I tested on Antutu, got score about 56000, normal level should be 72000.

Maybe because we did some tweaks on sched?

@sjllls I "fixed" that on my XZ2 by forcing max frequency while doing the benchmark. Probably you got the same "issue" that the phone doesn't force max frequencies for benchmark numbers. :P

[sjllls]

@sjllls I "fixed" that on my XZ2 by forcing max frequency while doing the benchmark. Probably you got the same "issue" that the phone doesn't force max frequencies for benchmark numbers. :P

Yup, lock freq could solve this problem, but it will cause battery drain when daily use. XD

You know, pdx201 have LineageOS based on SODP. But UI lag also appears on it. I suspect that there is something wrong with our scheduler because it needs to be compatible with some old HMP devices when compiling.

[MartinX3]

@sjllls I "fixed" that on my XZ2 by forcing max frequency while doing the benchmark. Probably you got the same "issue" that the phone doesn't force max frequencies for benchmark numbers. :P

Yup, lock freq could solve this problem, but it will cause battery drain when daily use. XD

You know, pdx201 have LineageOS based on SODP. But UI lag also appears on it. I suspect that there is something wrong with our scheduler because it needs to be compatible with some old HMP devices when compiling.

Yeah, I helped him bringing up the LOS for the pdxx201 :D

That's interesting As far as I know the XZ2/3 (including my XZ2) were fine there, only the XZ2C had an UI lag making the device unusable.

And you don't need to lock the frequencies to have a heater in the winter :P It will use the max frequency if a task needs it, just the benchmark seems not to be such a heavy task which needs a frequency rampage :)

[MarijnS95]

@MarijnS95 Did you noticed pdx201 get lower CPU performance than normal sdm665 level? I tested on Antutu, got score about 56000, normal level should be 72000.

Sorry to burst your bubble but I don't care at all about synthetic benchmarks nor gaming performance for that matter. If the device is stable and has no sluggish UI (which is a bug) that's enough for me.

As said before I'm only interested in such quality-of-life improvements on mainline, where efforts live on longer than a single LTS kernel release.

[sjllls]

@MarijnS95 I think most of time I met UI lag.(On SODP LineageOS, AOSP is much better). So I test with a benchmarks tool. Here are the Graphs of "Profile HWUI rendering", most of them are over red line(16ms, feel lag). Even my sdm630 device is much better than this.

My sharp sdm630 device.

[MarijnS95]

@sjllls That seems to be a LOS problem then, scrolling around in settings gives the same as your Sharp S2, all frames are pretty much on time. Jumping around between apps gives similar spikes, which is to be expected.

This is all about burst performance of the entire SoC, not sustained multicore CPU performance measured by these synthetic benchmarks.

[sjllls]

Tried to revert the kernel/sched and kernel/cpu.c to CAF, UI lag is still exist, so it should not be caused by our changes on schedule. Contunie finding the reasons.

[faenil]

Has there been any update on this in the last year? :smile:

Bad UI performance seems to still be an issue on Apollo AOSP11 r46 with OEMv9a (15th Feb 2022) binaries.

The UI is jittery and laggy, even just opening the application drawer is not smooth.

Interestingly enough, I did not notice this when I tested AOSP12 on Apollo

[faenil]

Not sure if this was the case for your guys too, but a lot of the UI lags are gone on my Apollo (not all of them, WIP), after I fixed https://github.com/sonyxperiadev/bug_tracker/issues/757

Have a look at it, if you're still waiting on a fix for this :)

[krnlyng]

Hi, i'm not sure if this is relevant here, but we see a memory leak on 4.14. Namely task_struct seems to be leaking according to some tests we've made.

It doesn't always happen, but in some tests task_struct leaks a few 100MB.

CONSIDER EVERYTHING BELOW THIS SPECULATION.

My (current) assumption is that it has to do with OOM handling itself.

Note 1: On kernel 4.14 it seems that CONFIG_MEMCG is ENABLED, while on kernels that are NOT 4.14 it seems to be DISABLED.

When fork fails due to oom_score_notify_new: https://github.com/sonyxperiadev/kernel/blob/aosp/LA.UM.7.1.r1/kernel/fork.c#L1957 we "goto" https://github.com/sonyxperiadev/kernel/blob/aosp/LA.UM.7.1.r1/kernel/fork.c#L2013 and eventually delayed_free_task is being called.

I'm not sure if this goto is ever taken, but if it is this might apply:

This brings me to https://github.com/sonyxperiadev/kernel/blob/aosp/LA.UM.9.14.r1/kernel/fork.c#L1795 which has different behaviour when CONFIG_MEMCG is enabled and not.

When it's not enabled the task is free'd immediately. When it's enabled then the task is freed "delayed". But i wonder that since the task never started that "delayed" thing might also never happen? I do not yet know if this is the case, but i currently see no other reason why task_struct would leak.

Thus my idea would be a patch like this:

diff --git a/kernel/fork.c b/kernel/fork.c
index 27075b55056b..17df544115e9 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1603,6 +1603,7 @@ static __latent_entropy struct task_struct *copy_process(
 {
        int retval;
        struct task_struct *p;
+       int free_task_immediately = 0;

        if ((clone_flags & (CLONE_NEWNS|CLONE_FS)) == (CLONE_NEWNS|CLONE_FS))
                return ERR_PTR(-EINVAL);
@@ -1954,8 +1955,10 @@ static __latent_entropy struct task_struct *copy_process(
                if (thread_group_leader(p)) {
 #ifdef CONFIG_OOM_SCORE_NOTIFIER
                        retval = oom_score_notify_new(p);
-                       if (retval)
+                       if (retval) {
+                               free_task_immediately = 1;
                                goto bad_fork_cancel_cgroup;
+                       }
 #endif
                        init_task_pid(p, PIDTYPE_PGID, task_pgrp(current));
                        init_task_pid(p, PIDTYPE_SID, task_session(current));
@@ -2060,7 +2063,11 @@ static __latent_entropy struct task_struct *copy_process(
 bad_fork_free:
        p->state = TASK_DEAD;
        put_task_stack(p);
-       delayed_free_task(p);
+       if (free_task_immediately) {
+               free_task(p);
+       } else {
+               delayed_free_task(p);
+       }
 fork_out:
        return ERR_PTR(retval);
 }

But again: I do not know if this is the issue here. Or if this is the explanation for our memory leak, i'm in the process of testing.

Let me know if i should put this into a seperate bug ticket.

[jerpelea]

Discontinued Android version