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 8091FD42BB3 for ; Tue, 12 Nov 2024 17:16:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 149D96B00E3; Tue, 12 Nov 2024 12:16:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0FA606B00E7; Tue, 12 Nov 2024 12:16:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EB68D6B00E8; Tue, 12 Nov 2024 12:16:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id C8D2A6B00E3 for ; Tue, 12 Nov 2024 12:16:15 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 77C0E8047A for ; Tue, 12 Nov 2024 17:16:15 +0000 (UTC) X-FDA: 82778095848.02.F33B029 Received: from mail-oo1-f42.google.com (mail-oo1-f42.google.com [209.85.161.42]) by imf10.hostedemail.com (Postfix) with ESMTP id C1293C0024 for ; Tue, 12 Nov 2024 17:15:54 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=kernel-dk.20230601.gappssmtp.com header.s=20230601 header.b=3Unv8+Id; spf=pass (imf10.hostedemail.com: domain of axboe@kernel.dk designates 209.85.161.42 as permitted sender) smtp.mailfrom=axboe@kernel.dk; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731431630; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=tnwYJHTHAIT7NhrPIR59Xh9wM+nrsn1VWuRs7Z2BGss=; b=8Htp1fi8dlWFlOEG9pqN2ve3tAlVjZnVRvDklpQom0PHwmMwlTr+fsdjTyH+Z96+crwUUd IISaiZvdMe+ZXnT4T9j2zhP2ZgYlkFnf+SZY2hYEFGwree8qe83NUGuWoBdfcE4XWxRyFL qKnlDXXXx+lJHlIAOzEAK57rp9fXwQI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731431630; a=rsa-sha256; cv=none; b=u3miBXE4oNXdfjh4/JtmraJt24dqMsTN+1dPUaRDDSBNVAR6MZYXxy7hPjmDvXzrEWQeXF nyX4Q7rZRy2B+tCkPbGFQQtqzgK3JpGefT4I6wdR17r3P7GzQ9Pjuf4vOmwN6gpcqxRVv/ GbLlpXX31wKRwsn/m9NPWmdVdDRkxk8= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=kernel-dk.20230601.gappssmtp.com header.s=20230601 header.b=3Unv8+Id; spf=pass (imf10.hostedemail.com: domain of axboe@kernel.dk designates 209.85.161.42 as permitted sender) smtp.mailfrom=axboe@kernel.dk; dmarc=none Received: by mail-oo1-f42.google.com with SMTP id 006d021491bc7-5eb73ec1e1aso2877442eaf.2 for ; Tue, 12 Nov 2024 09:16:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20230601.gappssmtp.com; s=20230601; t=1731431772; x=1732036572; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=tnwYJHTHAIT7NhrPIR59Xh9wM+nrsn1VWuRs7Z2BGss=; b=3Unv8+IdtzX8/XaIObVYTr10MqLx5cgfBzYEGV0UYV2JE2y/GzF5h47JHHoTnZ/r0p BSg+JKjpmbNZ74PnvNmUy3xFPAbDqrfX8hQdrX0JK/o5zmxzFjGDNl8nlILYWtJETjE/ +aOTKN0U5u/FMFIc2R2BNgLSPllKDQorvDeaj8uHwtQHQXR5vak4yzROQIUWzRvnXDeU CANzKXv4YY0x9FN6Pu6zsguv46/cDJzrVxeNOPZrgeT6lcq//47QfVeE2pk4d4XhmJR/ hry/fBSb0LqRhmW/ibb8a5sOGk2ZpHexuSvq5ktcMe1LhXC2F7GYGh0U+syGuEXjjU8y nzhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731431772; x=1732036572; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=tnwYJHTHAIT7NhrPIR59Xh9wM+nrsn1VWuRs7Z2BGss=; b=JuYqhxquk3aZY0V53FqZQI0DySRIJAWBQVk+eyMp+PkkhN0h+8HmlFxR0t8g4yqKVq NTOVqm8qf6Z1GRmO2LXpBpnn3uUEdJOhW0Lh95qsRO2/QHcHy8vJCZnFf6OLcOZrDcDG 0eq1bgeWVoY0281iJizjAMcD+g0j/yDMOS/QRCZXTe008cCQUNgywMvz9oeEiqW6OBwU jw8OBDRNEYGsAnKhZkYH/loo0NkyXxm6/wJIMPX6Fz7+mRWkoUgFV76QcAZqHNarAZWy Q4FTtJqJaGxqyceTz0ZW0lB16xw90ILmX5Sbx09stmTe5diLOrLlNlcii/U72Bi57uzh u8Vw== X-Gm-Message-State: AOJu0Ywqeb9S/iQvOGekHgylDJB4WfT4ClBZ+yVltbVTs3XbaP1JkHHF DQhXJQp8o8U75Z5JfSdt3f9tDig4H2pTrM9VB+TR7+anyhRXfmjE6DcfmrLPOZc= X-Google-Smtp-Source: AGHT+IG7wz2TGObI3XCZLc6czEW3NEVtcJxYLSH6bVzUApdp4Zu/FDc4eOSHYLi8nQ/yqwWNP9VyFg== X-Received: by 2002:a05:6820:4c85:b0:5eb:6c26:1ca0 with SMTP id 006d021491bc7-5ee57b9d3f9mr11631558eaf.1.1731431772373; Tue, 12 Nov 2024 09:16:12 -0800 (PST) Received: from [192.168.1.116] ([96.43.243.2]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-71a1080fb77sm2816311a34.20.2024.11.12.09.16.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Nov 2024 09:16:11 -0800 (PST) Message-ID: Date: Tue, 12 Nov 2024 10:16:10 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 13/16] iomap: make buffered writes work with RWF_UNCACHED To: Brian Foster Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, hannes@cmpxchg.org, clm@meta.com, linux-kernel@vger.kernel.org, willy@infradead.org, kirill@shutemov.name, linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org References: <20241111234842.2024180-1-axboe@kernel.dk> <20241111234842.2024180-14-axboe@kernel.dk> Content-Language: en-US From: Jens Axboe In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: C1293C0024 X-Stat-Signature: 4m5ajpmwagw7mfobnfzboiozhdm9497n X-HE-Tag: 1731431754-458985 X-HE-Meta: U2FsdGVkX1/KJU+RJ7OObc/3/O+KIfHUvBQBr00E5Hl3T0m1hqKNk12xj+JKP42fkctd49Gd75Pldcn+HqdQPastbUo6XnJcWqTKpvxDBvCnIAOQkIEl40uyyElzvNMx0DI8V1D6aVaiaokJ3SLx6JITi7GrkOC0LoH7N1xOTrcPg/EhDZmi1qm09ZYvRyaZKKRgIblfb4eVV7WT2GwROmYSyXe1DOObAt0pkJNzr+5VoOheYZWAf1aYcTYhs9BlfsVa6cRkgDrlM+YvsEu4uhlKdgfpM4RiO+RO5XZCcu2nCO2cKjU68ixQEk4KYYj+1nU1vS/8zl/itAOeBmf93rfUpripisxOL+ebsPTft/6Ez17rZ3xEFrMT8LTgcjLCU3xviVPFhKBmoor/f/fJXD27ACfklkuovlMx+Vms1tBVSihjRapfT6pF8JjDR+jn35DJEJzhFC3LZHXUgqwiDuK6Vqw76yECXNV+vfaJLHV17fJeVEkToCdpU3rvRTlQkQUHwwyVy5s9GUMxyVUQ3pRA82P/wloGwjD6s+dw5neSj4kbXtXp/aABanIII6lpQjQjElfUBOC82IzaWgQHv646uM5+9yaUeERgChTAueOQz7hnWANYGTl286Ctk8dSvG1KQnCv2XZKkKhqrnKAnLXn05mozQ393wfaAkkLFyYjwNYmJB6tKqW8OicP8jd0/l1ZxHaSKph1AwATvt9bCMs0tN2ZUFiF+W43aprgWJQB5rU17OTfNvcAQmCZ3MsYDNT1TzJVp+Wn0DjYdeV9C2bqFM9OCV+QAT1onn3AVIRxRFZ8wbisTUEk8LlPRq1JaQUajkmbRm5HS5JmbyDkjawaFZSU1N5OhXeedyFClQfrKJxmtu2Z9GdaU5IfQFiyZQB+r+DJXa5wAszvUJjFw45RUYKmAFRFb32HaApjx8FBGtj30pHLB+y0+6PJWenglyCoxEnVGquMNo7d/lC 61WBFSPw YmkmWasLMlaCgGARC9E0HqQcOmcVdfjG31kDAJkZjkBPnqgb07dVpcrjBLi+GdYIJ+Vb7QBQNkb8j65neCvVtTKpdk/fw04QwY21cqRp9SWCtGVpKJKfFail3eaYOtMial69bQiyvsZi7sp8BXHLfC50Hwz5L4i8/pOjHnZZAWF9ma+vgQejLuU5V3V8XQ7pLDkuFqJ8X7j9noHyC0ij8A6FquxfGZ5WpIOjtA5Bopi7zfv4qTVzjTnzEsVsehmDkB7lEEfA0Jfdb2HRSSC1vgojjlKQJdK+Gp4JJdDACIG9jNO4nVOWEAq1lfveqHT8R3C3wiwZRyzb+FlQFTxHwwa/HNcIfJuW3nx6eeKRMi5dWGE+q/aAe4GdE704rFEXvHy552hVPIPWuTy5h3XLfMEYYDw== 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: List-Subscribe: List-Unsubscribe: On 11/12/24 9:37 AM, Brian Foster wrote: > On Mon, Nov 11, 2024 at 04:37:40PM -0700, Jens Axboe wrote: >> Add iomap buffered write support for RWF_UNCACHED. If RWF_UNCACHED is >> set for a write, mark the folios being written with drop_writeback. Then > > s/drop_writeback/uncached/ ? Ah indeed, guess that never got changed. Thanks, will fix that in the commit message. > BTW, this might be getting into wonky "don't care that much" territory, > but something else to be aware of is that certain writes can potentially > change pagecache state as a side effect outside of the actual buffered > write itself. > > For example, xfs calls iomap_zero_range() on write extension (i.e. pos > > isize), which uses buffered writes and thus could populate a pagecache > folio without setting it uncached, even if done on behalf of an uncached > write. > > I've only made a first pass and could be missing some details, but IIUC > I _think_ this means something like writing out a stream of small, > sparse and file extending uncached writes could actually end up behaving > more like sync I/O. Again, not saying that's something we really care > about, just raising it in case it's worth considering or documenting.. No that's useful info, I'm not really surprised that there would still be cases where UNCACHED goes unnoticed. In other words, I'd be surprised if the current patches for eg xfs/ext4 cover all the cases where new folios are created and should be marked as UNCACHED of IOCB_UNCACHED is set in the iocb. I think those can be sorted out or documented as we move forward. UNCACHED is really just a hint - the kernel should do its best to not have permanent folios for this IO, but there are certainly cases where it won't be honored if you're racing with regular buffered IO or mmap. For the case above, sounds like we could cover that, however, and probably should. -- Jens Axboe