On Mon, Jul 13, 2026 at 10:23:43AM -0400, Steven Rostedt wrote:

On Mon, 13 Jul 2026 12:16:59 +0900
Masami Hiramatsu (Google) [off-list ref] wrote:

quoted

quoted

I also kept this around in case it was needed. Looks like it may be needed.  

Hmm, it's not clear whether this is the result of a scheduling storm
caused by kernel threads. But maybe worth to try.

I don't see what else it could be.

quoted

Jeongho, can you try this patch? Or/and you maybe also try using
mlock the LMKD process memory which is passed to trace_marker.

Yes, Jeongho, can you please test this patch and also see if mlocking the
memory used by trace_marker would help too?

-- Steve

Hi Steven adn Masami,

Sorry for the delayed response.
I would like to share the current situation.

This issue occurred during the verification process of our latest Exynos
chip development.
Unfortunately, this problem is not being further reproduced.
We have continued testing the unmodified kernel on about 40 devices for
roughly 10 hours per day for approximately one week.

Because the baseline kernel no longer reproduces the problem at a
measurable rate, I do not think that a test with the proposed patch, or
with the LMKD buffer mlocked, would currently allow us to determine
whether either change improves the issue. A non-reproduction with the
patch would be indistinguishable from the current baseline result.

Versions that can be deployed for verification with a large
number of devices are limited to official release-ready versions.
I can only test the test patches you shared by building them
individually and testing them on the few devices I have.

Therefore, at this point I cannot provide a conclusive test result for
the proposed patch. I can still perform limited build and functional
testing on a small number of devices, but I would not be able to verify
whether the patch changes the reproduction rate.

Thanks,
Jeongho