ULE steal_idle questions

[Jan Bramkamp]

On 26.08.17 21:58, Don Lewis wrote:
> On 26 Aug, To: kostikbel at gmail.com wrote:
>> On 26 Aug, Konstantin Belousov wrote:
>>> On Sat, Aug 26, 2017 at 11:29:29AM -0700, Don Lewis wrote:
>>>> I actually haven't noticed that problem on my package build boxes.  I've
>>>> experienced decent interactive performance even when the load average is
>>>> in the 60 to 80 range.  I also have poudriere configured to use tmpfs
>>>> and the only issue I run into is when it starts getting heavily into
>>>> swap (like 20G) and I leave my session idle for a while, which lets my
>>>> shell and sshd get swapped out.  Then it takes them a while to wake up
>>>> again.  Once they are paged in, then things feel snappy again.  This is
>>>> remote access, so I can't comment on what X11 feels like.
>>> I believe what people complain about is the following scenario:
>>> they have some interactive long living process, say firefox or mplayer.
>>> The process' threads consume CPU cycles, so the ULE interactivity
>>> detection logic actually classifies the threads as non-interactive.
>>>
>>> This is not much problematic until a parallel build starts where
>>> toolchain processes are typically short-lived.  This makes them
>>> classified as interactive, and their dynamic priority are lower than the
>>> priority of long-lived threads which are interactive by user perception.
>>>
>>> I did not analyzed the KTR dumps but this explanation more or less
>>> coincides with the system slugginess when attempt to use mplayer while
>>> heavily oversubscribed build (e.g. make -j 10 on 4 cores x 2 SMT
>>> machine) is started.
>> I can believe that.  I keep an excessive number of tabs open in firefox
>> and it would frequenty get into a state where it would consume 100% of a
>> CPU core.  Very recent versions of firefox are a lot better.
>>
>> Xorg is another possible victim.  I've just noticed that when certain
>> windows have mouse focus (firefox being one, wish-based apps are
>> another) that the Xorg %CPU goes to 80%-90%.  I think this crept in with
>> the lastest MATE upgrade.  If Xorg is treated as non-interactive, then
>> the desktop experience is going to be less than optimal if there is
>> competing load.
> I've got poudriere running right now on my primary package build box.
> The priorties of the compiler processes are currently in the range of
> 74-96.
>
> On my desktop, firefox is running at priority 24.  Xorg when it is not
> being a CPU hog gets all the way down to priority 20.  When the mouse is
> pointing to one of the windows that makes it go nuts, then it gets all
> the way up to priority 98.
On my old desktop (AMD Phenom II X6 1060T) which doubled as poudriere 
compile server I wrapped Xorg and moused with cpuset and rtprio. It 
solved my problem, but felt wrong.