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 A9826C531DC for ; Fri, 23 Aug 2024 11:59:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 34AF880091; Fri, 23 Aug 2024 07:59:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2FA0580084; Fri, 23 Aug 2024 07:59:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 19BAD80091; Fri, 23 Aug 2024 07:59:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id EB91F80084 for ; Fri, 23 Aug 2024 07:59:17 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 7D45C121C92 for ; Fri, 23 Aug 2024 11:59:17 +0000 (UTC) X-FDA: 82483364754.08.CEDB51B Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf07.hostedemail.com (Postfix) with ESMTP id C66A24000A for ; Fri, 23 Aug 2024 11:59:15 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=zIqhtD1w; dmarc=none; spf=none (imf07.hostedemail.com: domain of BATV+ff4ea1235fcdd8feb3bf+7670+infradead.org+hch@bombadil.srs.infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=BATV+ff4ea1235fcdd8feb3bf+7670+infradead.org+hch@bombadil.srs.infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724414295; a=rsa-sha256; cv=none; b=pWQ5c2dw+s7cHm+JWGmQADUBfi0HqsOuix7amp5IHXdpFAR20KmWo78hHDvQcKz3OH8cBO g8piwZQkJiex5DeF1+wPdjssvnBGHZRhWQ/np9YgzuWmaZ5GmbN/a7lhDyN7tSkvurP+bu MzTBHnTQI+N8etB9ksY6uDKrg95a2xA= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=zIqhtD1w; dmarc=none; spf=none (imf07.hostedemail.com: domain of BATV+ff4ea1235fcdd8feb3bf+7670+infradead.org+hch@bombadil.srs.infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=BATV+ff4ea1235fcdd8feb3bf+7670+infradead.org+hch@bombadil.srs.infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724414295; 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=MXxJTuEfTmUxd6qScc9KjmTA55na5LtJXZN9+i18IuU=; b=OjuDXWtPlClqx4yhVmIxdVguBT3StQWdGHEXjE5PpScbJkWLqdMHbgIXcoX5OyE8wX/n0m 9x5r51lE5AIrS8SETGf8nm879Mc8O+MM/RectWyiEUrc56DYVlK64yoCVZnm+H85vAdB2g 2xYWg9Hs28+usXDnWVROTOu8CdoiTVA= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Transfer-Encoding :Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=MXxJTuEfTmUxd6qScc9KjmTA55na5LtJXZN9+i18IuU=; b=zIqhtD1whjn1MefVjKeXFaIJ9C DYkAQQrts0+YUEXxY7CtCXDicxh3HJFiSNw9O8g4enC89obYJhEKIuf8gKiuL1q7SIdsklbpbKe+q eMmU86bfUk0nJ6oUhQZvLrapCPhcZZvimd0+34tCqHcULnsdiAIC6iSYo6NC6EY3ldnfHFkZDdMff On9SGDsZRg8NLMmwKRUAOHZ5eyO6k1XRI1RAYkh6oqaJq86WJ32pCAy4mQVjwHOiOrKapcn23p/nT oQBrPj+8hsD01KYhjM0FOYeoqsEPJ5L0UcHigFglOIWqgW7DibNFeR/fi2UA0Je4bey+QGz6qfKGs 8mxvzfSw==; Received: from hch by bombadil.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1shSwj-0000000GbyR-0QHj; Fri, 23 Aug 2024 11:59:13 +0000 Date: Fri, 23 Aug 2024 04:59:13 -0700 From: Christoph Hellwig To: Pavel Begunkov Cc: Christoph Hellwig , io-uring@vger.kernel.org, Jens Axboe , Conrad Meyer , linux-block@vger.kernel.org, linux-mm@kvack.org, dchinner@redhat.com Subject: Re: [PATCH v2 5/7] block: implement async discard as io_uring cmd Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-Rspamd-Queue-Id: C66A24000A X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: c3c6zp1rc3gq5o9ygkq41984nazkxjtt X-HE-Tag: 1724414355-736199 X-HE-Meta: U2FsdGVkX1/Rwx0U1wY17ZNvaEvfmgwYvGLuX5mnRu4QQ/H2Uy9kJ+44NmEnaaGyB+Yr98s2HBs9xuNd+Ldl7TBQeRFuJ2rfQRLYXXKOs/kSFMQHwtDpK0Tbqdr+tmKx2JTCNs74neR9awOosnrNiRwDZrQphbUOn32I/EiN2TnxLoe9+8Yn2Oo4GXLRajOzR4UrmPBebLFEIHoDJXPGo1g8+RLqVrGOGE22dDoBTJcm2VOMePucMC2+94nPTuyjEfGZvv7jyxNblBBiwdZRPzPWrKdYuQ7CMlbmJP6TXl1DD2QuXzzuPwSP2YSKxPO1JHwCT6nohtukbITb6pXWa4n9rTpEvzE+AaFoB95+NIYMln7XCnRG+sDIK3OHMhZ+a1yml+2wluQtjN+UoaCr8QKVypyH/gtSkv0tHsZ6qut57nhMKt1B00h27wsbuNMmG5dLMqVzVT11pbCSl8sb8JkjE3NyB37iUzXd9uezJVByXqb9HumNRVDDAZUV5nh0zfGB6/7dvTXldRUyyAt14xOJoOhMrqlxH5doPdvCOkI6bg+WyjNUsL6kqnYS9d80iUFrAXWfUm86PjORF+EDkIN6WcZvLTW3Dolls2eKwPuWoH1RNFF/t4jGtc5SrvtgAgO72MeR2VXALD/ldhAYfeT2fj2cD2WwsT9bpFXMZOKL+2yAAivqinpS3nvSgvF4e1HxHMJ9ed0Et3MIoDxKdy/QAxCb3mXDos/uusFsdh64DWO5jotjp8DPQjatjdK6LutPz8pg7A7hoXfGnlfRmsL5qiuHXoFDcmP9Grc5cyPiEQRy43gN4nZCJdaAokmJIwNRPKgVyocdsAJ/gT8QFPabAfbMI+QHgMwwpAfXdfH2KiE27SNm/M/aBGVQW2tErcl45iTCK1qgQUyFqeMCdUCXe2q8HlEcs9YBWgWfOkN6NHJCjVVJUoEnN4tppYtLvpwmkVNzDoj5khRa9b/ ZPKvlsT8 zV9nnBFMPlZOqPf/j51TVRQ4JVgI0qxE6KUuJ6ZIQg7sn37aAqBLfK/hdlXkhHUB06ia7VyWsdlNwVZQqfOrvlAWRlXnFWrtPhYrntIByBmwd9/xN3hKk/S/nA/BwA7ZHPxshRONNw/3S+T5EE0YsxqA6lUWD34GCDB0fHJqkqUglVudA6ko5TdZnvR6AiVofF2uzcJFe4Utu603CHj9IRqZk6XSHFKWmnaMHWeGyhusqnCOWTnd7ZWJ267iP24hMGAW9b1B9O4+0LhQBZ/OZ9uRrIIhzGtbMH22i3i1kia3lVySvSSKxt1Ft1x+8+e/uwihqnX0ngShNrDwsiDXeeQNZZp6GqekO3x3fuNv1rG03DP1eD4K/luWDmFhh3hSfvL/dc0TVqZYOzmL+14/YEd8luoIvE+iyVFrUV5gOWHXHH1RNRqY6gZfh5wWEeGcoCKRAm9WAWy0mlyw8Ux/YhmGxZm4Lipm3QH6Mo1u7ubHrKse9mRK8enyqc3cFd8ditM59GPOWsShEtJ0uXkZeFzGY6A4DRbWH8xKsJdFFD38l2wSYEqIGlILcm9iJQ0n4sutxx3xlGonaMgFCiASrU34HC8+SLmVh+3Wg 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 Thu, Aug 22, 2024 at 02:07:16PM +0100, Pavel Begunkov wrote: > > > Note, unlike ioctl(BLKDISCARD) with stronger guarantees against races, > > > we only do a best effort attempt to invalidate page cache, and it can > > > race with any writes and reads and leave page cache stale. It's the > > > same kind of races we allow to direct writes. > > > > Can you please write up a man page for this that clear documents the > > expecvted semantics? > > Do we have it documented anywhere how O_DIRECT writes interact > with page cache, so I can refer to it? I can't find a good writeup. Adding Dave as he tends to do long emails on topic like this so he might have one hiding somewhere. > > GFP_KERNEL can often will block. You'll probably want a GFP_NOWAIT > > allocation here for the nowait case. > > I can change it for clarity, but I don't think it's much of a concern > since the read/write path and pretty sure a bunch of other places never > cared about it. It does the main thing, propagating it down e.g. for > tag allocation. True, we're only doing the nowait allocation for larger data structures. Which is a bit odd indeed. > I'd rather avoid calling bio_discard_limit() an extra time, it does > too much stuff inside, when the expected case is a single bio and > for multi-bio that overhead would really matter. Compared to a memory allocation it's not really doing all the much. In the long run we really should move splitting discard bios down the stack like we do for normal I/O anyway. > Maybe I should uniline blk_alloc_discard_bio() and dedup it with uniline? I read that as unŃ–nline, but as it's not inline I don't understand what you mean either. > > > +#define BLOCK_URING_CMD_DISCARD 0 > > > > Is fs.h the reight place for this? > > Arguable, but I can move it to io_uring, makes things simpler > for me. I would have expected a uapi/linux/blkdev.h for it (and I'm kinda surprised we don't have that yet). > > > Curious: how to we deal with conflicting uring cmds on different > > device and how do we probe for them? The NVMe uring_cmds > > use the ioctl-style _IO* encoding which at least helps a bit with > > that and which seem like a good idea. Maybe someone needs to write > > up a few lose rules on uring commands? > > My concern is that we're sacrificing compiler optimisations > (well, jump tables are disabled IIRC) for something that doesn't even > guarantee uniqueness. I'd like to see some degree of reflection, > like user querying a file class in terms of what operations it > supports, but that's beyond the scope of the series. We can't guaranteed uniqueness, but between the class, the direction, and the argument size we get a pretty good one. There is a reason pretty much all ioctls added in the last 25 years are using this scheme.