Re: Periodic rant about SCHED_ULE

Quoting George Mitchell <george+freebsd@m5p.com>:

>> https://forums.freebsd.org/threads/what-is-sysctl-kern-sched-preempt_thresh.85
>>
>Thank you!                                             -- George

You're welcome. Can I get a success/failure report?


---------------------------------------------------------------------
>> On 3/22/23, Steve Kargl <sgk@troutmask.apl.washington.edu> wrote:
>>>
>>> I reported the issue with ULE some 15 to 20 years ago.

Can I get the PR number, please?


---------------------------------------------------------------------
Test usecase:
=============

Create two compute tasks competing for the same -otherwise unused- core,        
one without, one with syscalls:                                                 
                                                                                
# cpuset -l 13 sh -c "while true; do :; done" &                                 
# tar cvf - / | cpuset -l 13 gzip -9 > /dev/null                                
                                                                                
Within a few seconds the two task are balanced, running at nearly the           
same PRI and using each 50% of the core:                                        
                                                                                
  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND  
 5166 root          1  88    0    13M  3264K RUN     13   9:23  51.65% sh       
10675 root          1  87    0    13M  3740K CPU13   13   1:30  48.57% gzip     
                                                                                
This changes when the tar reaches /usr/include with it's many small             
files. Now smaller blocks are delivered to gzip, it does more                   
syscalls, and things get ugly:                                                  
                                                                                
  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND  
 5166 root          1  94    0    13M  3264K RUN     13  18:07  95.10% sh       
19028 root          1  81    0    13M  3740K CPU13   13   1:23   4.87% gzip     
                                                                                
This does not happen because tar would be slow in moving data to               
gzip: tar reads from SSD, or more likely from ARC, and this is                  
always faster than gzip-9. The imbalance is made by the scheduler.