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 F31A3EED617 for ; Thu, 12 Sep 2024 16:38:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 891CE6B0089; Thu, 12 Sep 2024 12:38:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 842396B008C; Thu, 12 Sep 2024 12:38:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 709F16B0092; Thu, 12 Sep 2024 12:38:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 4CBBC6B0089 for ; Thu, 12 Sep 2024 12:38:18 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 02F59A7BC0 for ; Thu, 12 Sep 2024 16:38:17 +0000 (UTC) X-FDA: 82556643876.13.FF9B785 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) by imf16.hostedemail.com (Postfix) with ESMTP id 05DB7180004 for ; Thu, 12 Sep 2024 16:38:15 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=R7q1MRwS; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf16.hostedemail.com: domain of asml.silence@gmail.com designates 209.85.128.52 as permitted sender) smtp.mailfrom=asml.silence@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726159010; a=rsa-sha256; cv=none; b=VzbruuBWzn0u8O1fRqhUMmIq5eu80Y/dgqwQ56w9eRzz+RCj6wJtAw6pJVs99pvHnR0cFH DT+Y0Mjl63KHb5jyZv6N1hLqxDN4VzvDTwQeAXwVJi6QOoTAnnsoIqzeNIZQuaAbMiMrGO ola4A0/+uf3aJ+dCMSRzTuZsvRhxWuI= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=R7q1MRwS; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf16.hostedemail.com: domain of asml.silence@gmail.com designates 209.85.128.52 as permitted sender) smtp.mailfrom=asml.silence@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726159010; 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=ke8B8ei/VwftxZT7up985lGEeDI1fMW74nZ+B/Yl1e0=; b=JIV1RwXZGVmJRNJQw6ZiiGzMAiPz1vzGzhdLmLA4uqnheEYWcZaGhYFjd9cyyB3yqdbgF5 vNWYeyT3ORd2PNBRs0qtJp7UkPvwX9K/X8gH7Y5IdJreJtwz73mIy4JgBz42v5c5e3foWD WHXeLVJPyTMlFNaF93Zq5jrY0CfWvZc= Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-42cacabd2e0so10599945e9.3 for ; Thu, 12 Sep 2024 09:38:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726159094; x=1726763894; 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=ke8B8ei/VwftxZT7up985lGEeDI1fMW74nZ+B/Yl1e0=; b=R7q1MRwSZltW3w1j65M4nfOX9pWq3h9EZAPM1sitWdGRaExLLmvkcgftyqR8CBPyr6 UJedrPnbkuHjnnTyGJXifFAG2xDsmfHtLkWkOT3sWFvMRn4H2wz7q2uefSK1AiFEiG3J rz/QtPE1rfRTOcb6W9GDb8b1HBdJehDcy1wfmA1VCvpE7bPscmamYmel8xFUiq9JcXG/ spUmq/DVkCuUMQbD2/qYVOAb/RfAGkpD4HN47v0EvWhnJWQbHn0P4pnhAP1DX27KlCye KUjhoiGPs29AuzVbLrkS6VX3VJcIKPWJHjE3FNYgQzXoG8xiBqTFiO9/M/B8eAVJCUwe qHJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726159094; x=1726763894; 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=ke8B8ei/VwftxZT7up985lGEeDI1fMW74nZ+B/Yl1e0=; b=WoyPnorwBD+IZFgLWmApyMAAcUSOG1yYIcVgypoa0zq6MrlBCeMWcvSVdB2hDOqhyR joQyjpNqP+5XPnRiVZmPV0ARYcKfH8RMWLw7BoRVz202ke5e3XPWTQJuoY3YeHDAJedx OWJ89R191kIz1zubxgCj4AIsaf90IjaWdzJ8sVsJBcG7LJt+Y/dnw25sO550M6zrNgNb RG646W5jEyN54gaEgN3aBqJ7I7xk6haa7WyBmRnlQH1OoEGD04wD55jAKICfGxUkcO9W NCNKp/zywcj9m1i3dtqckYDYk+LigTOzWt311OMyxOuVOnvagJiMLkZLImTk5bKdLKlj a0FA== X-Forwarded-Encrypted: i=1; AJvYcCVxkh8xsoFRIViq8TFflhGtwP+v/LDJnMeKY9zjGJ0uF6j7APKi8p0CJcxh+l2TbusojRuJlv4Lvg==@kvack.org X-Gm-Message-State: AOJu0Yxn8BtzjfExV1np34LOGk9bTbFfgrsyLLaHOCWBrlfdJppS4JO7 K/t5PIBy8kvyiPOj2JhRIuIh9OlTZG9aX8Mm+YHau4gf4/441HUi X-Google-Smtp-Source: AGHT+IHS4iIBmRPXS44yHXJrmVIJWvFhF6iTvnEiniY4uPDRvmSCo0v65F86PcBLdF4iVV2pB87G5Q== X-Received: by 2002:a05:6000:1561:b0:374:93c4:2f61 with SMTP id ffacd0b85a97d-378c2cfecaamr2880974f8f.5.1726159093692; Thu, 12 Sep 2024 09:38:13 -0700 (PDT) Received: from [192.168.42.65] ([148.252.141.246]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-378956dbf58sm14795352f8f.94.2024.09.12.09.38.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Sep 2024 09:38:12 -0700 (PDT) Message-ID: Date: Thu, 12 Sep 2024 17:38:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 8/8] block: implement async write zero pages command To: Christoph Hellwig Cc: io-uring@vger.kernel.org, Jens Axboe , Conrad Meyer , linux-block@vger.kernel.org, linux-mm@kvack.org References: Content-Language: en-US From: Pavel Begunkov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 05DB7180004 X-Stat-Signature: m3sqry9pdw8jcwkojhfm6ca66hmab3tk X-Rspam-User: X-HE-Tag: 1726159095-175298 X-HE-Meta: U2FsdGVkX1/IOh66QrwEif68bL1cuk9tQL/OO16hbxOThFO5tRzh949b5B8y/5pympgAxJKHzih803jF43awvrArxk5qa+qXDjVyWQRvasHgi3EsPyMMTfpJ+0l8LvRv8pryeZqoTJLwqIxsc2XuJZsHdjrY4TJqVx1Qpl8Ja8KN0+vJhGY3pf4wwdKBpaDraGx4lLb6/hnuFGtvE+jLEe0zFInL47aCYMF14G7A29u5V8Aqn9mRJ9wtQW+GNUhE15wB2RXviVQ0Qj2AH01shQy2YrL2Mj0x5apcrSU7mGW7H6egIbw6lITrTuev4RksNvJu7Ioek24lzI7jFUvW/hvt0mUJ/Xd+CoSIAp6RUezv0hZ3EqEzUYEWIUj3Hk5vwKNBTci5m+ElFd6M6dNfx92nCDiw15oQQj5hZjGywfph7Rb4ps/r0YVKVHo1PPDvCIp1UmsxJCu9tm3ZB3h7mv+O7IHHS9Z8PkENXqgOCI6HSGvBuBVkd9Ud0WD2ySIdXUdzw/c/WWuq/wDonMLrgDQdizzphg1K9iOhrZvViAl6jgsubqE8aQeffMSC6WjX02pH1BktXHCGEIN8aPr4ev5jl60Fgp8AYrUMyIVeAF1r0LNphqRJwB3+Cz9i3Ku+1vtoRu8jYXaQ0ODS12bvV/9Ick5hB8FiSqKOC+Tq20eeToi1DGbsnUBNse2sbfLTow6PHgQt4r3Z9LMvYiFSBMANzZj0pHae3lRPc0QjiR3rmwYJ0Js6HaX9DNvYpSAdXtAablVJvPUq4SWQ7mUEpTRb9lD+lRt53/JMIIuIBaAxk6xh6ctsb4U5m4I4DEe09H/kUZjeoaXAQWyzYBkjXlMKpGGhXzq4Pava5bPY+YuoLfsgZex2Ud9r2qL0rNrABcvJA8p8I6iiqrHYVs0aqKXnu0m/KWtOOaxwg4jZiggSIJ8zyz/3PBLFzQ51aCsEX4FP9oHPMTLzSUakqzG 5YUDTsPi 6u2k+q1RXaynig/sJE/9MW8tQxvPOcX6IIz192obLekBlix4yxGC3qevJgT3fwuWaAyIsZoryWOUR1cxfayI3QsY8JPJwK8VBvgZ7/YVcvo9JVO8xSA213xrKTR+dAIRXYhUhqv2acgd+h4Usv+aHWcpd8XoE/K8ioYqkXZokxlbVi15KtOb1uL/htUxeoJLJdnF9GzOVQJYC+nT1nGbbd+xFXPieOjy7j9d/Svo36e3WG8PjylSiIoxmZOtUWUQTAAVtq1T17gx+V+DnrAJfcUVxP5O/d32uE2hWKoqtWIcWykC3LSlhUejXQUINUq6iF221sTXEb7xBJaw1ZY3ewtZ5oab0YUrrTkzJdqUS3LN8XnBmhwHm2xDx0AzaNU5tLcFQweOqG4LtwnnH/0SwBHFRq7P5PTAIlIfw3HkIKgm7eRaxqUPStRzQ1w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.009632, 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 9/12/24 10:26, Christoph Hellwig wrote: > On Tue, Sep 10, 2024 at 09:10:34PM +0100, Pavel Begunkov wrote: >> If we expect any error handling from the user space at all (we do), >> it'll and have to be asynchronous, it's async commands and io_uring. >> Asking the user to reissue a command in some form is normal. > > The point is that pretty much all other errors are fatal, while this > is a not supported for which we have a guaranteed to work kernel Yes, and there will be an error indicating that it's not supported, just like it'll return an error this io_uring commands are not supported by a given kernel. > fallback. Kicking it off reuires a bit of work, but I'd rather have > that in one place rather than applications that work on some hardware > and not others. There is nothing new in features that might be unsupported, because of hardware or otherwise, it's giving control to the userspace. >> That's a shame, I agree, which is why I call it "presumably" faster, >> but that actually gives more reasons why you might want this cmd >> separately from write zeroes, considering the user might know >> its hardware and the kernel doesn't try to choose which approach >> faster. > > But the kernel is the right place to make that decision, even if we > aren't very smart about it right now. Fanning that out to every > single applications is a bad idea. Apart that it will never happen >> Users who know more about hw and e.g. prefer writes with 0 page as >> per above. Users with lots of devices who care about pcie / memory >> bandwidth, there is enough of those, they might want to do >> something different like adjusting algorithms and throttling. >> Better/easier testing, though of lesser importance. >> >> Those I made up just now on the spot, but the reporter did >> specifically ask about some way to differentiate fallbacks. > > Well, an optional nofallback flag would be in line with how we do > that. Do you have the original report to share somewhere? Following with another flag "please do fallback", at which point it doesn't make any sense when that can be done in userspace. -- Pavel Begunkov