Scudo performs badly when MTE is enabled, specifically on Google Doodle page [374073118]

Assigned

Bug

[AOSP] assigned

Status Update

No update yet.

Description

ta...@arm.com

created issue #1

Oct 17, 2024 04:39PM

I was investigating the Champion Island Google Doodle game performance on a Pixel 8 device with MTE enabled, in a developer build of the Chromium project configured with full mte option enabled (that means I've used the flag use_full_mte=true in my args.gn while compiling Chromium). The "Full MTE" option implies MTE in sync mode, currently. Android version is [ro.build.description]: [aosp_shiba-userdebug 14 AP1A.240405.002 eng.xxxxxx.20240412.155842 test-keys]

The Doodle performs very badly (decreased framerate) with this configuration. Looking into the simpleperf reports, it shows Scudo consuming a high %, specially considering the time spent on collectStackTrace:

8.77%     CrGpuMain        16381  16414  [kernel.kallsyms]                                              el0_svc_common                                                                        
6.56%     CrGpuMain        16381  16414  /apex/com.android.runtime/lib64/bionic/libc.so                 android_unsafe_frame_pointer_chase                                                    
5.59%     CrGpuMain        16381  16414  /apex/com.android.runtime/lib64/bionic/libc.so                 sigaltstack                                                                           
4.34%     CrGpuMain        16381  16414  /apex/com.android.runtime/lib64/bionic/libc.so                 scudo::Allocator<scudo::AndroidNormalConfig, &(scudo_malloc_postinit)>::collectStackTrace()                                                                                                                                                                                         
3.08%     CrGpuMain        16381  16414  [kernel.kallsyms]                                              _raw_spin_unlock_irqrestore                                                           
1.70%     CrGpuMain        16381  16414  /apex/com.android.runtime/lib64/bionic/libc.so                 scudo::HybridMutex::unlock()                                                          
1.69%     CrGpuMain        16381  16414  [kernel.kallsyms]                                              __seccomp_filter                                                                      
1.42%     CrGpuMain        16381  16414  /vendor/lib64/hw/android.hardware.graphics.mapper@4.0-impl.so  arm::mapper::common::get_metadata(private_handle_t const*, arm::mapper::common::MetadataType const&, std::__1::vector<unsigned char, std::__1::allocator<unsigned char> >&)

Callstack wrt sigaltstack:

Children  Self    Command              Pid    Tid    Shared Object                                   Symbol
314.55%   96.34%  CrGpuMain            16381  16414  /apex/com.android.runtime/lib64/bionic/libc.so  sigaltstack
       |
       -- sigaltstack
          |
           --76.55%-- scudo::Allocator<scudo::AndroidNormalConfig, &(scudo_malloc_postinit)>::collectStackTrace()
               |
               |--50.58%-- scudo::Allocator<scudo::AndroidNormalConfig, &(scudo_malloc_postinit)>::storePrimaryAllocationStackMaybe(scudo::Options const&, void*)
               |           scudo::Allocator<scudo::AndroidNormalConfig, &(scudo_malloc_postinit)>::allocate(unsigned long, scudo::Chunk::Origin, unsigned long, bool)
               |    |
               |    |--99.23%-- scudo_malloc
               |    |           malloc
               |    |    |
               |    |    |--75.01%-- operator new(unsigned long)
               |    |    |    |
               |    |    |    |--26.92%-- android::hardware::hidl_string::operator std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >() const
               |    |    |    |    |
               |    |    |    |    |--63.63%-- android::gralloc4::encodeMetadataType(android::hardware::graphics::mapper::V4_0::IMapper::MetadataType const&, android::gralloc4::OutputHidlVec*)
               |    |    |    |    |    |
               |    |    |    |    |    |--34.44%-- android::gralloc4::encodePixelFormatFourCC(unsigned int, android::hardware::hidl_vec<unsigned char>*)

Expected behaviour: Scudo performance shouldn't be affected that much in the presence of MTE (Regardless of the MTE mode).

Looking into the code, it looks like when MTE is in Sync mode, Scudo has it's own stack trace tracking mechanism (https://android.googlesource.com/platform/bionic/+/master/libc/bionic/heap_tagging.cpp#83)

I tried manually disabling it by calling scudo_malloc_set_track_allocation_stacks(0) from application code (Chromium), but seems like it is a local symbol in Bionic, which means I cannot call it.

If this is not a bug and it is the expected behaviour, then I'd like to ask if there is any way I can use MTE on sync mode and disable the stack trace tracking on Scudo?

Comments

ra...@google.com <ra...@google.com> #2Oct 18, 2024 05:48AM

Assigned to ra...@google.com.

I see same issue and have been debugging it.

NOTE: It DOES NOT happen if not using support package, but use android level 14/15 library. I believe Honeycomb works well too.

My current workaround is to provide my own DialogFragment.show() method, like below:

public int show(FragmentTransaction transaction, String tag) {
return show(transaction, tag, false);
}

public int show(FragmentTransaction transaction, String tag, boolean allowStateLoss) {
transaction.add(this, tag);
mRemoved = false;
mBackStackId = allowStateLoss ? transaction.commitAllowingStateLoss() : transaction.commit();
return mBackStackId;
}

eu...@google.com <eu...@google.com> #3Oct 21, 2024 11:17PM

[Comment deleted]

1.patch

3.4 KB

View

Download

ta...@arm.com <ta...@arm.com> #4Oct 23, 2024 02:12PM

But Google pls fix this issue, as the expected behaviors must be consistent with ICS DialogFragment + FragmentManager and support package DialogFragment + FragmentManager.

It happens with both Support Package v4 r6 and v13 r6.

eu...@google.com <eu...@google.com> #5Oct 28, 2024 06:26PM

I have this problem too.

As a workaround I use a boolean in the onActivityResult to mark the desired dialog and show the dialog in the onResume.

ta...@arm.com <ta...@arm.com> #6Oct 29, 2024 02:28PM

Extra info on stackoverflow:

http://stackoverflow.com/questions/10114324/show-dialogfragment-from-onactivityresult

Issue 374073118