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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7AB89C4338F for ; Sat, 24 Jul 2021 19:46:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E1FBE60C41 for ; Sat, 24 Jul 2021 19:46:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E1FBE60C41 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 343136B006C; Sat, 24 Jul 2021 15:46:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2EFB76B0071; Sat, 24 Jul 2021 15:46:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1B7666B0070; Sat, 24 Jul 2021 15:46:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0085.hostedemail.com [216.40.44.85]) by kanga.kvack.org (Postfix) with ESMTP id F2FC46B0033 for ; Sat, 24 Jul 2021 15:46:07 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 8C9548249980 for ; Sat, 24 Jul 2021 19:46:07 +0000 (UTC) X-FDA: 78398512374.02.90FE038 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by imf22.hostedemail.com (Postfix) with ESMTP id 24E8FA031 for ; Sat, 24 Jul 2021 19:46:07 +0000 (UTC) Received: by mail-pj1-f51.google.com with SMTP id a4-20020a17090aa504b0290176a0d2b67aso5473882pjq.2 for ; Sat, 24 Jul 2021 12:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=SaRVMIPsR4RUT0xlMnKQjQMMszZ0iueZl2tGoIzLrJM=; b=FNnF3e0uYRIU4gSyLJfdlw7+kMTm7aNiVoiIg+bnba8zFWIMy4Ef+tApv3CbTY3wNR MwIU3QiAYVwVvQIFmhzx6sFDrftBF4y+DQJY5LnBmS4Vi8BnahJAOZflcSEIA5DhU6U5 7g30HUKxH+mbzdacHLcZ4DPAIWVHE63QKozAl5UVvFyK2nSb1OJUItHZfyI/wYV/J4D9 9M/JQ95+XQaOxD8z7ZB0WdayvPyhY5nqYCD04/+izy7b6eXRin8McVhmHLh5mEHA9OHQ pOfC+HDW3GfQLG6u4ZJrORNQy9St2KJmjK85mkhiNm1EafXSgNeSCrwcQnbxILNp0cmj jyvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SaRVMIPsR4RUT0xlMnKQjQMMszZ0iueZl2tGoIzLrJM=; b=EnUyXMN1AThljjXmEUym+kS8+aUio/gHIsDjH9gKHNtRzKcP1sAyG4CKpCLKsIuHAi 3xdveviLdVxeXPKy+1EA/135DM6C8XPBFIK99heRB6vhsCArYFHTI8znIK6smMhP6biD 5HK4QHuZPkhq7NKVrMVY9WcDnu7bD7IqIAaIrU5QrlXVM5JfYP7/KOHuhIQJYAd4a5Ca QGmKs0WmyCmPPKZBCX7pTrYqLPuizWYZhmKU2XidCE682N40bQ29rXJhyWmSUsKYZv6L HctQF6uCDEYetMbd9SuY+ktdfZ9cB+x8mPoOBAkXIfOTJXzVe/y7abGxvIMMkcmeOddB P0Xw== X-Gm-Message-State: AOAM532d/SQ1yipeJgm9hRr2uxxbrIJkPc3GtPKCnH/qVA66qNlhXQtF vc6WBXKItoDQwNuevW1GcbL4/Q== X-Google-Smtp-Source: ABdhPJylawTGN3h+Z+h36hC8P3jWa6Xs90tk7UGNIstd8gOZaOSwuboq4WYd8TNMxYvPmRp5FY83pg== X-Received: by 2002:aa7:8751:0:b029:32b:560a:b17f with SMTP id g17-20020aa787510000b029032b560ab17fmr10492603pfo.32.1627155965856; Sat, 24 Jul 2021 12:46:05 -0700 (PDT) Received: from [192.168.1.187] ([198.8.77.61]) by smtp.gmail.com with ESMTPSA id y7sm35336773pfi.204.2021.07.24.12.46.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 24 Jul 2021 12:46:05 -0700 (PDT) Subject: Re: [PATCH 0/2] Close a hole where IOCB_NOWAIT reads could sleep To: Matthew Wilcox Cc: io-uring@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-aio@kvack.org References: <20210711150927.3898403-1-willy@infradead.org> From: Jens Axboe Message-ID: <5b0e9558-0bb0-c2b0-2125-b8d33a1c3360@kernel.dk> Date: Sat, 24 Jul 2021 13:46:03 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 24E8FA031 Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=FNnF3e0u; dmarc=none; spf=pass (imf22.hostedemail.com: domain of axboe@kernel.dk designates 209.85.216.51 as permitted sender) smtp.mailfrom=axboe@kernel.dk X-Stat-Signature: oz1t7gttr18wae51nz1awsm6t3h9upkf X-HE-Tag: 1627155967-555751 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 7/24/21 12:22 PM, Matthew Wilcox wrote: > On Sun, Jul 11, 2021 at 07:44:07PM -0600, Jens Axboe wrote: >> On 7/11/21 9:09 AM, Matthew Wilcox (Oracle) wrote: >>> I noticed a theoretical case where an IOCB_NOWAIT read could sleep: >>> >>> filemap_get_pages >>> filemap_get_read_batch >>> page_cache_sync_readahead >>> page_cache_sync_ra >>> ondemand_readahead >>> do_page_cache_ra >>> page_cache_ra_unbounded >>> gfp_t gfp_mask = readahead_gfp_mask(mapping); >>> memalloc_nofs_save() >>> __page_cache_alloc(gfp_mask); >>> >>> We're in a nofs context, so we're not going to start new IO, but we might >>> wait for writeback to complete. We generally don't want to sleep for IO, >>> particularly not for IO that isn't related to us. >>> >>> Jens, can you run this through your test rig and see if it makes any >>> practical difference? >> >> You bet, I'll see if I can trigger this condition and verify we're no >> longer blocking on writeback. Thanks for hacking this up. > > Did you have any success yet? Sorry forgot to report back - I did run some testing last week, and didn't manage to make it hit the blocking condition. Did various read/write mix on the same file, made sure there was memory pressure, etc. I'll give it another go, please let me know if you have an idea on how to make this easier to hit... I know it's one of those things that you hit all the time in certain workloads (hence why I would love to see it get fixed), but I just didn't manage to provoke it when I tried. -- Jens Axboe