1. Forum
  2. Usenet
  3. LINUX.DEBIAN.USER

  • Xorg process priority relative to applications causing apparent desktop

    From Glen Wetzel@21:1/5 to All on Thu Jul 24 23:30:01 2025
    This is a multi-part message in MIME format.
    Hello Debian.org,
    _
    __Problem description:_
    I have noticed that when desktop screen applications peg cpu usage, such
    as by having many browser tabs open or a bug in a web page's javascript,
    the windowing system X appears to freeze so that the offending
    application cannot be closed by the user.  The mouse and keyboard are non-responsive requiring a power cycle reboot.

    _To replicate:_
    Open many tabs on your browser to heavy javascript pages or other high
    screen usage sites such as youtube.com.  System will become
    non-responsive.  Mouse with lag and then freezes.  Keyboard and mouse
    become useless.

    _Apparent cause_
    When entering the top command on a Debian system, it can be seen that
    the Xorg process is at the same priority as screen applications such as Browsers, email, xterms, etc.  User screen control of X should take
    priority over general application processes.  Currently, I perform a workaround by the following root command:

    # renice -12 -p $(pgrep Xorg)

    It seems also desirable that some screen apps have high process priority
    than other apps.  For example, xterms to have higher priority than other applications such a chromium browser tab processes.  Should the Xorg
    process have a higher priority over the user application screen
    processes on Debian installs?  If yes, what package to report, etc. or ?

    Thank you,
    Glen Wetzel




    <html>
    <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    </head>
    <body text="#000000" bgcolor="#FFFFFF">
    <font size="-1">Hello Debian.org,<br>
    <u><br>
    </u><u>Problem description:</u><br>
    I have noticed that when desktop screen applications peg cpu
    usage, such as by having many browser tabs open or a bug in a web
    page's javascript, the windowing system X appears to freeze so
    that the offending application cannot be closed by the user.  The
    mouse and keyboard are non-responsive requiring a power cycle
    reboot.<br>
    <br>
    <u>To replicate:</u><br>
    Open many tabs on your browser to heavy javascript pages or other
    high screen usage sites such as youtube.com.  System will become
    non-responsive.  Mouse with lag and then freezes.  Keyboard and
    mouse become useless.<br>
    <br>
    <u>Apparent cause</u><br>
    When entering the top command on a Debian system, it can be seen
    that the Xorg process is at the same priority as screen
    applications such as Browsers, email, xterms, etc.  User screen
    control of X should take priority over general application
    processes.  Currently, I perform a workaround by the following
    root command:<br>
    </font><tt><br>
    </tt><tt># renice -12 -p $(pgrep Xorg)</tt><font size="-1"><br>
    <br>
    It seems also desirable that some screen apps have high process
    priority than other apps.  For example, xterms to have higher
    priority than other applications such a chromium browser tab
    processes.  Should the Xorg process have a higher priority over
    the user application screen processes on Debian installs?  If yes,
    what package to report, etc. or ?<br>
    <br>
    Thank you,<br>
    Glen Wetzel<br>
    <br>
    <br>
    <br>
    </font>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nicolas George@21:1/5 to All on Fri Jul 25 13:10:01 2025
    Glen Wetzel (HE12025-07-24):
    __Problem description:_
    I have noticed that when desktop screen applications peg cpu usage, such as by having many browser tabs open or a bug in a web page's javascript, the windowing system X appears to freeze so that the offending application
    cannot be closed by the user. The mouse and keyboard are non-responsive requiring a power cycle reboot.

    _To replicate:_
    Open many tabs on your browser to heavy javascript pages or other high
    screen usage sites such as youtube.com. System will become non-responsive. Mouse with lag and then freezes. Keyboard and mouse become useless.

    Does your problem happen also when the programs eating the CPU are not graphical? You can test with this:

    for i in $(seq 50) ; do openssl speed & done

    Also, I do not observe the issue you mention. I suspect a problem with
    your video drivers is more likely.

    It seems also desirable that some screen apps have high process priority
    than other apps.

    Linux has since a long time heuristics to adjust the priority of apps
    depending on their use (interactive or batch) and their interactions;
    niceness is only one parameter in these heuristics.

    Regards,

    --
    Nicolas George

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nicolas George@21:1/5 to All on Sun Jul 27 12:20:01 2025
    Glen Wetzel (HE12025-07-26):
    1.* Tried this command on an xterm:

    $ for i in $(seq 50) ; do openssl speed & done

    Whether the renice was applied to the Xorg task or not, the screen does not lock up and I can successfully pkill. So, no problem.

    Nice.

    *3.* The problem observed is consistent of having the windowing system task (Xorg) being run at the same or less priority than the applications under
    the windowing system.

    No, it is not: you had xterm and it subprocess eating all your CPU and
    nothing happened.

    Last night I was lucky to capture some evidence that exemplifies the problem. I left the machine with a renice higher Xorg priority (top value 8). The next morning, it can be seen that the chromium window became non-responsive and would draw a replicated image mess from other windows
    when mousing over. However, the windowing system remained responsive. See screenshot.

    This is not normal and proves that what you propose is not a fix but
    just a partial countermeasure.

    On 7/25/25 4:04 AM, Nicolas George wrote:

    Top-posting is contrary to the etiquette of this list.

    Regards,

    --
    Nicolas George

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Glen Wetzel@21:1/5 to All on Sun Jul 27 14:20:01 2025
    No, it is not: you had xterm and it subprocess eating all your CPU and nothing happened.

    The xterm openssl script does not exemplify the problem since it does
    not exercise graphics I/O.  The issue is that the Xorg task is being
    starved when screen application tasks are at the same or higher priority
    level than the Xorg task.  Try the following:

    $ for i in $(seq 50) ; do chromium --new-window https://www.youtube.com/watch?v=10f4899srvc & done

    Click the each of the windows to give focus and start the videos. Notice
    that the screen seems to freeze on common laptops.

    Now try again by first setting the priority of the Xorg task to be
    higher than the screen applications:

    # renice -12 -p $(pgrep Xorg)
    $ for i in $(seq 50) ; do chromium --new-window https://www.youtube.com/watch?v=10f4899srvc & done

    Click the each of the windows to give focus and start the videos. See
    that now the windowing system is responsive to the user so that the
    chromium windows can be closed.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nicolas George@21:1/5 to All on Sun Jul 27 14:30:01 2025
    Glen Wetzel (HE12025-07-27):
    The xterm openssl script does not exemplify the problem since it does not exercise graphics I/O.  The issue is that the Xorg task is being starved when screen application tasks are at the same or higher priority level than the Xorg task.

    Precisely. Now remember that “the Xorg task” is supposed to do the
    graphics on behalf of the clients.

    Regards,

    --
    Nicolas George

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)