Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [RFC PATCH] io-wq: kill cpu hog worker
To:     Hillf Danton <hdanton@sina.com>
Cc:     io-uring@vger.kernel.org, viro@zeniv.linux.org.uk,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-mm <linux-mm@kvack.org>
References: <20191223024145.11580-1-hdanton@sina.com>
 <20191224115415.1360-1-hdanton@sina.com>
From:   Jens Axboe <axboe@kernel.dk>
Message-ID: <b91775e3-e6f4-d5dc-0790-60599c96dfd3@kernel.dk>
Date:   Tue, 24 Dec 2019 09:13:30 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <20191224115415.1360-1-hdanton@sina.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 12/24/19 4:54 AM, Hillf Danton wrote:
> 
> On Mon, 23 Dec 2019 08:15:00 -0700 Jens Axboe wrote:
>>
>> On 12/22/19 7:41 PM, Hillf Danton wrote:
>>>
>>> Reschedule the current IO worker if it is becoming a cpu hog.
>>
>> Might make more sense to put this a bit earlier, to avoid the
>> awkward lock juggle. In theory it shouldn't make a difference
>> if we do it _before_ doing new work, or _after_ doing work. We
>> should only be rescheduling if it's running for quite a while.
>>
>> How about putting it after the flushing of signals instead?
> 
> 
> All right, thanks.
> 
> Hillf
> --->8---
> From: Hillf Danton <hdanton@sina.com>
> Subject: [RFC PATCH] io-wq: kill cpu hog worker
> 
> Reschedule the current IO worker to cut the risk that it is becoming
> a cpu hog.
> 
> Signed-off-by: Hillf Danton <hdanton@sina.com>
> ---
> 
> --- a/fs/io-wq.c
> +++ b/fs/io-wq.c
> @@ -432,6 +432,8 @@ next:
>  		if (signal_pending(current))
>  			flush_signals(current);
>  
> +		cond_resched();
> +
>  		spin_lock_irq(&worker->lock);
>  		worker->cur_work = work;
>  		spin_unlock_irq(&worker->lock);
> --

That looks better, applied.

-- 
Jens Axboe