From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id AA6C2C77B61 for ; Tue, 25 Apr 2023 08:00:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 185C26B0074; Tue, 25 Apr 2023 04:00:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 135C86B0075; Tue, 25 Apr 2023 04:00:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F3F936B0078; Tue, 25 Apr 2023 04:00:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id E302C6B0074 for ; Tue, 25 Apr 2023 04:00:58 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id ABEA2C01F2 for ; Tue, 25 Apr 2023 08:00:58 +0000 (UTC) X-FDA: 80719167396.18.DE9B1B2 Received: from outbound-smtp35.blacknight.com (outbound-smtp35.blacknight.com [46.22.139.218]) by imf10.hostedemail.com (Postfix) with ESMTP id AA73DC0022 for ; Tue, 25 Apr 2023 08:00:56 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=none; spf=pass (imf10.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.139.218 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682409657; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XNctmVb5wFnTOj2zhSnCLm5uiWTL+XqxcJ23KKtrBTo=; b=RYxnPrI/hCrlFJd2KtJXvFN5UdBwCBSoOyAtwf4Rv18kQ77i1tHnOLof7rdhgZWmWgaJiW x/3RokxXcfN1iKJsn336AdrCd5ZTIkUxSH5nsXKLJGS0wGW99PoSVxX3GGcR0HHYJJEfGT ttyjV55wvD1M39iq0Fk2Vx876OQ0Vzk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682409657; a=rsa-sha256; cv=none; b=dI54Bmrs+OwGmuRwdog623cQ4ZRiQYRUo3KrLoVW2UXmuRsqNcS+7dGAcQy9TlmefTXVlA w75qwGxM7N+DV36duRQhNcYv06KfoJvNXEY21ZqEyJ30CvuwIv3/zjatvrsQ0/N5UZVqj6 S0GBTijXefft/54buGcNONMq4GyCCEc= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none; spf=pass (imf10.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.139.218 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net; dmarc=none Received: from mail.blacknight.com (pemlinmail02.blacknight.ie [81.17.254.11]) by outbound-smtp35.blacknight.com (Postfix) with ESMTPS id 75EDE1D43 for ; Tue, 25 Apr 2023 09:00:54 +0100 (IST) Received: (qmail 23226 invoked from network); 25 Apr 2023 08:00:54 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.21.103]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 25 Apr 2023 08:00:54 -0000 Date: Tue, 25 Apr 2023 09:00:52 +0100 From: Mel Gorman To: Doug Anderson Cc: Andrew Morton , Vlastimil Babka , Ying , Alexander Viro , Christian Brauner , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Yu Zhao , linux-fsdevel@vger.kernel.org, Matthew Wilcox Subject: Re: [PATCH v2 1/4] mm/filemap: Add folio_lock_timeout() Message-ID: <20230425080052.63dik4aadlrjvd2p@techsingularity.net> References: <20230421221249.1616168-1-dianders@chromium.org> <20230421151135.v2.1.I2b71e11264c5c214bc59744b9e13e4c353bc5714@changeid> <20230424082254.gopb4y2c7d65icpl@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: AA73DC0022 X-Rspamd-Server: rspam09 X-Stat-Signature: zsqnnskx1cjbjgh755yytzqybjq9j34z X-HE-Tag: 1682409656-75164 X-HE-Meta: U2FsdGVkX18qTlbDVoS9+IeBn4YgoA738NJ9W5P9e4BWwyriqrd3j+kQ46/mEOvyGpS3kQfmTyBoFPKv006bLXaEtgb5Rq0Gi3GIfsDCf5UpOKrOkbnMmj+GiDeaa11IyYX2DjV1ayD2A4oMFHqbMxT7Y4SFDZvAOHmO6E+gZTu18kP8sU986gn/X94hpPtKnVBlX5R5amAu2doSg5JYE2T/GTE7FPR+7xl6I8BMiTLWRVcP4g3fhNu+3xDoSeNrq3SiqRaH4OAxdtJGzv5srvvW9pZyNRtZhFZbzxcAOtWUa5/IpjsJWJb4wWu+AorltbzZm8HRWpyNpznQaVvA8gubUhN/ipx+3IX40AoAFhkjrBNY8nZji/mGWCEOEDWMkOEnwNlLYKVB7PyYwEzlD10xCuao9Rlbz9Q+wjkAaDet1zfQUj/o1fODBvWdu7Yn3rZIc02kom3HGWbxVm50HrFgpRl9drrgxCaXMRcehKwttGaOQgJgO2VUtHZxNTvHpekaFttsd8Xjr+PGzFMplp7qjTkkKXFYIDxMWOlaPKUhR82DkIUK86iW8TuFktR5MWmBa3fah6b7Ww4SFlbFCMxZNGDD4y/oAAvyXda5BefS6nH5M4Q7Sgw0lRbgucPqFI8O32rzrXwzkGhxJpPWw77PP+6YLXmmo7LBDx7J/j8uVuo1JRCFNe4JTD+vy9/eJvGaxnJRy6/d3mgAN+QgGOHmjgJpzxeVpQYGbe4bFmbB8JMBwS3QeO+V23fM6lRumqfQtWF6PyR2D45xF4mr2w72y0llRlVFKXGCH831XoA0s1VbbLJeVBVRAd/RPUkjqq6LHqcV3AK8JCFZ8FPNELQ+3LxRTA8hBW+iSjTC3TCaF+LWuT1+pIenXAgWIMKNAugpN5kq7fjxcF1QTnINomWmZIg+y0t9AJl9PFKXMYK8JnuyI7uCGgd7ymAa1QLHpO4221AzZaNYsEurvNU AwWvZnc/ aftvNFFToBd/UtgyVW148llPrVUrH+2AeINiZNmjcmMlQ60Xgxa5DIrmTRVJNwxDWkjL+mMkd5OxOS7jVvoTcQSwr1ofs3kqbluk3nOtNLzuSE3uAoXtUWHtPlH01bxU5neFcz8mKlzhL9W2Ar4ocBXR7gV6aZDyx9jeqomuwTBGsaenazN+s7gjeqSGLwN5ZOPpc6o1NApS4PjuwgmBTVC4pCedYYTZmKiwWaa9gqFtxmUc3joxAbMc3LRTq72ymSKKa+tRMX1O6LWQ3e4rf3PQcPw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Apr 24, 2023 at 09:22:55AM -0700, Doug Anderson wrote: > Hi, > > On Mon, Apr 24, 2023 at 1:22???AM Mel Gorman wrote: > > > > > @@ -1295,10 +1296,13 @@ static inline int folio_wait_bit_common(struct folio *folio, int bit_nr, > > > /* Loop until we've been woken or interrupted */ > > > flags = smp_load_acquire(&wait->flags); > > > if (!(flags & WQ_FLAG_WOKEN)) { > > > + if (!timeout) > > > + break; > > > + > > > > An io_schedule_timeout of 0 is valid so why the special handling? It's > > negative timeouts that cause schedule_timeout() to complain. > > It's not expected that the caller passes in a timeout of 0 here. The > test here actually handles the case that the previous call to > io_schedule_timeout() returned 0. In my patch, after the call to > io_schedule_timeout() we unconditionally "continue" and end up back at > the top of the loop. The next time through the loop if we don't see > the WOKEN flag then we'll check for the two "error" conditions > (timeout or signal pending) and break for either of them. Ah, I see! > > To make it clearer, I'll add this comment for the next version: > > /* Break if the last io_schedule_timeout() said no time left */ Yes please. -- Mel Gorman SUSE Labs