From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-132.freemail.mail.aliyun.com (out30-132.freemail.mail.aliyun.com [115.124.30.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2AE4F175A7B for ; Wed, 22 Apr 2026 01:46:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.132 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776822401; cv=none; b=fV+J6dnfFG9WU9hS8bY++KjjPEuhR766I3ApPmWbcslzMJrV7YWRTfHUvZ9H2zpgECH2bp3Lt0cv7z0GW+Iyv47iwjmRYIH06xMoxGfBUgUzrOt66OCunbBd/mBD1Q7xgbOJXCYu0C/E5VC103ACiR5pnG3UQbPBLkxAXETgtUg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776822401; c=relaxed/simple; bh=C+ufUDH1HoAK/fWPqibBxsUAs1+IS9qJZFbkRsJikbw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=hm4/scgfyw+7gXb0weFCNAIoos0kmZ+JJAJLcvIwjnElbEh0zZvLCB6/qyfj4oswwAb+tvrhFNFHDwOnT/OJrOAGYUQ4Eund5Y5v8wVdK3BfwO94nISjxBFNC76qpx6U2RkMKwtIGYeLo54s+iMTakZwtolLLyRR+j55/rORaJw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=Sw0oA29z; arc=none smtp.client-ip=115.124.30.132 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="Sw0oA29z" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1776822390; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; bh=WtLKhpy2zmxEzkLBRuem7DAZe0cRQ7Pw3b6A7VAcH8Y=; b=Sw0oA29ziZXPL9vCeK5f093PpQeWNVojcPr8qBJ6opmbeSXX6kn0V6tn900ziMlxU7zTLzJveSb5UvF+6ivv7YNj1gq/2QOu9/88YyAFvGRGf8Yfvf8C/6QvsITpLJfuhjlf9aVQ+5GeFV5xLr+r4XcJba1XNyTDS5LQx0t5LPw= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R791e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037026112;MF=ying.huang@linux.alibaba.com;NM=1;PH=DS;RN=27;SR=0;TI=SMTPD_---0X1UPB-9_1776822387; Received: from DESKTOP-5N7EMDA(mailfrom:ying.huang@linux.alibaba.com fp:SMTPD_---0X1UPB-9_1776822387 cluster:ay36) by smtp.aliyun-inc.com; Wed, 22 Apr 2026 09:46:28 +0800 From: "Huang, Ying" To: John Hubbard , "David Hildenbrand (Arm)" Cc: Andrew Morton , Lorenzo Stoakes , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Zi Yan , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Gregory Price , Alistair Popple , Axel Rasmussen , Yuanchu Xie , Wei Xu , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , LKML , linux-mm@kvack.org Subject: Re: [RFC PATCH 0/2] mm/migrate: wait for folio refcount during longterm pin migration In-Reply-To: <51168a90-d6ad-4429-8043-3dfdd81cb9a3@kernel.org> (David Hildenbrand's message of "Tue, 21 Apr 2026 18:00:28 +0200") References: <20260410032333.400406-1-jhubbard@nvidia.com> <87h5p4isbb.fsf@DESKTOP-5N7EMDA> <51168a90-d6ad-4429-8043-3dfdd81cb9a3@kernel.org> Date: Wed, 22 Apr 2026 09:46:26 +0800 Message-ID: <878qafix71.fsf@DESKTOP-5N7EMDA> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=ascii "David Hildenbrand (Arm)" writes: > On 4/21/26 11:19, Huang, Ying wrote: >> Hi, John, >> >> John Hubbard writes: >> >>> Hi, >>> >>> This adds a bounded sleep to migration so that FOLL_LONGTERM pinning can >>> wait for transient folio references to drain, instead of failing after a >>> fixed number of retries. The wait uses a one-second timeout. An >> >> Is the one-second timeout appropriate for all users? Do some users >> prefer fail-fast behavior instead? If so, should we add another FOLL >> flag to support a timed wait? > > We should avoid a FOLL flag to affect that behavior. FOLL_LONGTERM > already implies that things could take a while. Yes. I am just not sure whether one-second is OK for all users. > So we have real examples were failing is even desirable? :) Hi, John, Could you do some research on this? --- Best Regards, Huang, Ying