Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <a7bcbcf2-9b34-4326-822f-e1f2aa5c5668@joelfernandes.org>
Date:   Sun, 23 Jul 2023 10:50:26 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.12.0
Subject: Re: [BUG] Re: Linux 6.4.4
Content-Language: en-US
To:     paulmck@kernel.org
Cc:     linux-kernel@vger.kernel.org, stable@vger.kernel.org,
        rcu@vger.kernel.org, Greg KH <gregkh@linuxfoundation.org>
References: <20230720132714.GA3726096@google.com>
 <2b8fc10b-785e-48b9-9a38-5c1af81f9578@paulmck-laptop>
 <CAEXW_YQO7OCdkXm_SBcPhAm8V8vMaF_5DQq7PbG9PZb7RFgA_g@mail.gmail.com>
 <f18e165c-9196-4b41-a202-82cfd5ac7f8b@paulmck-laptop>
 <8682b08c-347b-5547-60e0-013dcf1f8c93@joelfernandes.org>
 <eb04b7d0-2f49-4e01-be09-9062d9f08404@paulmck-laptop>
 <32aec6d1-bf25-7b47-8f31-7b6318d5238d@joelfernandes.org>
 <9b42cb38-8375-fc41-475a-2bd26c60a7b9@joelfernandes.org>
 <5dcf7117-cec7-4772-8aad-e100484a84dc@paulmck-laptop>
 <7bfde9f4-2bd6-7337-b9ca-94a9253d847f@joelfernandes.org>
 <ad82995c-061e-4f97-a972-c13a85ad0b72@paulmck-laptop>
From:   Joel Fernandes <joel@joelfernandes.org>
In-Reply-To: <ad82995c-061e-4f97-a972-c13a85ad0b72@paulmck-laptop>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 7/22/23 13:27, Paul E. McKenney wrote:
[..]
> 
> OK, if this kernel is non-preemptible, you are not running TREE03,
> correct?
> 
>> Next plan of action is to get sched_waking stack traces since I have a
>> very reliable repro of this now.
> 
> Too much fun!  ;-)

For TREE07 issue, it is actually the schedule_timeout_interruptible(1)
in stutter_wait() that is beating up the CPU0 for 4 seconds.

This is very similar to the issue I fixed in New year in d52d3a2bf408
("torture: Fix hang during kthread shutdown phase")

Adding a cond_resched() there also did not help.

I think the issue is the stutter thread fails to move spt forward
because it does not get CPU time. But spt == 1 should be very brief
AFAIU. I was wondering if we could set that to RT.

But also maybe the following will cure it like it did for the shutdown
issue, giving the stutter thread just enough CPU time to move spt forward.

Now I am trying the following and will let it run while I go do other
family related things. ;)

+++ b/kernel/torture.c
@@ -733,6 +733,6 @@ bool stutter_wait(const char *title)
                        ret = true;
                }
                if (spt == 1) {
-                       schedule_timeout_interruptible(1);
+                       schedule_timeout_interruptible(HZ / 20);
                        cond_resched();
                } else if (spt == 2) {