Renderer threads failed to be created with high priority |
||||||||
Issue descriptionChrome Version (from the about:version page):67.0.3365.0 Is this the most recent version:yes OS + version:Linux 3.8.13 CPU architecture (32-bit / 64-bit):armv7l What steps will reproduce the problem? (1)Run cast shell with extra switch disable-web-security and feature allow_user_media_access. (2)Cast a webpage that uses WebRTC to make VoIP call. (3)Run the above two steps again with extra switch --no-zygote and --no-sandbox. What is the expected result? Two tries should have similar behavior, or no-sandbox one has slightly better performance. What happens instead? In sandboxed case, audio processing cannot be real time, while w/o sandbox it can. By printing out log info, it shows that the audio device threads that runs the processing failed to be set to REALTIME priority when sandboxes are enabled. Please provide any additional information below. Attach a screenshot and backtrace if possible. For graphics-related bugs, please copy/paste the contents of the about:gpu page at the end of this report.
,
Mar 9 2018
As this issue is related to Sandbox, adding 'TE-NeedsTriageHelp' label for further help in triaging this issue. Thanks..
,
Mar 12 2018
,
Mar 13 2018
,
Mar 14 2018
This sounds like wai. Max you've been looking at thread priorities, can you shed light on this?
,
Mar 14 2018
As far as I know stock Linux doesn't allow ordinary users to raise priority at all, unrelated to sandboxing. On Linux machines with a special setup/special user allowing high-prio threads, maybe we can update the sandbox to allow the renderer to raise thread priorities as well? I don't know anything about how the sandbox works though.
,
Apr 9 2018
wfh@, can you comment on this? Is this wai?
,
Apr 19 2018
User needs to manually modify /etc/security/limits.conf to have proper RLIMIT_NICE to have sandboxed thread can be created with the right priorities. On our platform, we don't have PAM and thus don't have limits.conf, so I used a helper binary to set proper RLIMIT_NICE and fork itself to launch chrome. Render threads inherit the RLIMIT_NICE and can have proper priority now. Not sure if it is designed to be work in such way. But this is no longer an urgent bug/request to me.
,
Apr 20 2018
sorry I don't know about linux sandboxing, but it sounds like from comment 9 that this might not be an issue any more.
,
Apr 26 2018
Changing Pri to 2 based on #9. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by susan.boorgula@chromium.org
, Mar 9 2018