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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 07EE0C43603 for ; Wed, 11 Dec 2019 17:37:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9EE5220637 for ; Wed, 11 Dec 2019 17:37:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="LtAWLNJI" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9EE5220637 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 45A166B3320; Wed, 11 Dec 2019 12:37:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3E4946B3321; Wed, 11 Dec 2019 12:37:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2D2156B3322; Wed, 11 Dec 2019 12:37:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0158.hostedemail.com [216.40.44.158]) by kanga.kvack.org (Postfix) with ESMTP id 17ED36B3320 for ; Wed, 11 Dec 2019 12:37:44 -0500 (EST) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id AF0272489 for ; Wed, 11 Dec 2019 17:37:43 +0000 (UTC) X-FDA: 76253568006.01.cloth91_7d9a28f542502 X-HE-Tag: cloth91_7d9a28f542502 X-Filterd-Recvd-Size: 5471 Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Wed, 11 Dec 2019 17:37:42 +0000 (UTC) Received: by mail-lf1-f68.google.com with SMTP id m30so17323638lfp.8 for ; Wed, 11 Dec 2019 09:37:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/qPDI4CWJjC5/5bz94R850+eMWjiIMaPpEB5QatbHqs=; b=LtAWLNJIGgleEYyJY7SqUMGfF7zizqXB9fYINThzWBGo8tnYIl1k6mXoeKI7sQzQdq EPnru+FlO2NXMV0jrkNCbK7iiC4wwbei2gwxVjVLVdeaIlu64BeNLRHNskMdjZ4IKCGH RZm3Yapso6JOJSyQl9vuO5BT87Tpq60EJwBYI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/qPDI4CWJjC5/5bz94R850+eMWjiIMaPpEB5QatbHqs=; b=osLu0s+QLxViD6FqVOOhgT9ZMdrQth8DE5Hdto6W/eJJLHEQeMbIRo63Tn+QKPmErj X0n/k46hzDz8Su2OVwbj4d7Dteh4ONBAWagCoqy+ZT/JUJxvkJoKqqpjJobKARglhIKA f9GAWP28Aa5CpnSyewgMcQof3LSz2ukYEcuUotXl9Oe36vhAQC0kzy8jMueMVsasdKhf 5mRKAeKHL5y7GOFftDvjb/LkwTIfCDVmYjU2N45MXomb4kPTRi3f74JHEzf4Y7CyVpAc i9j2UbDrnA6KI37+sUUFYIiq2hByKnjP2/YJZpFt3MgHkz6sqs38qrJqiVYUJdjFQw26 ybKQ== X-Gm-Message-State: APjAAAW9NGU1OmsH5NIPJE/f1VftSFyB1s9z7sX7VUnrccVVn5MqpPFe q9YlIHhScjlx81DOuqpAe0+OVCbtyIA= X-Google-Smtp-Source: APXvYqwQIc+pwT3w+Zwi0wEOrwskaPtJw1LEbrIr6q/zOMyJr2Sc8sra5jFx36rqYGE4Lu76IibvzA== X-Received: by 2002:ac2:5623:: with SMTP id b3mr3120158lff.10.1576085860091; Wed, 11 Dec 2019 09:37:40 -0800 (PST) Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com. [209.85.208.173]) by smtp.gmail.com with ESMTPSA id w2sm1546265ljo.61.2019.12.11.09.37.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 Dec 2019 09:37:39 -0800 (PST) Received: by mail-lj1-f173.google.com with SMTP id k8so24960521ljh.5 for ; Wed, 11 Dec 2019 09:37:38 -0800 (PST) X-Received: by 2002:a2e:9041:: with SMTP id n1mr3004616ljg.133.1576085858434; Wed, 11 Dec 2019 09:37:38 -0800 (PST) MIME-Version: 1.0 References: <20191211152943.2933-1-axboe@kernel.dk> In-Reply-To: <20191211152943.2933-1-axboe@kernel.dk> From: Linus Torvalds Date: Wed, 11 Dec 2019 09:37:22 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCHSET v3 0/5] Support for RWF_UNCACHED To: Jens Axboe Cc: Linux-MM , linux-fsdevel , linux-block , Matthew Wilcox , Chris Mason , Dave Chinner Content-Type: text/plain; charset="UTF-8" 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 Wed, Dec 11, 2019 at 7:29 AM Jens Axboe wrote: > > Comments appreciated! This should work on any standard file system, > using either the generic helpers or iomap. I have tested ext4 and xfs > for the right read/write behavior, but no further validation has been > done yet. Patches are against current git, and can also be found here: I don't think this is conceptually wrong, but the implementation smells a bit. I commented on the trivial part (the horrendous argument list to iomap_actor), but I wonder how much of the explicit invalidation is actually needed? Because active invalidation really is a horrible horrible thing to do. It immediately means that you can't use this interface for normal everyday things that may actually cache perfectly fine. What happens if you simply never _activate_ the page? Then they should get invalidated on their own, without impacting any other load - but only when there is _some_ memory pressure. They'll just stay on the inactive lru list, and get re-used quickly. Note that there are two ways to activate a page: the "accessed while on the inactive list" will activate it, but these days we also have a "pre-activate" path in the workingset code (see workingset_refault()). Even if you might also want an explicit invalidate path, I would like to hear what it looks like if you instead of - or in addition to - invalidating, have a "don't activate" flag. We don't have all _that_ many places where we activate pages, and they should be easy to find (just grep for "SetPageActive()"), although the call chain may make it a bit painful to add a "don't do it for this access" kind of things. But I think most of the regular IO call chains come through "mark_page_accessed()". So _that_ is the part you want to avoid (and maybe the workingset code). And that should be fairly straightforward, I think. In fact, that you say that just a pure random read case causes lots of kswapd activity makes me think that maybe we've screwed up page activation in general, and never noticed (because if you have enough memory, you don't really see it that often)? So this might not be an io_ring issue, but an issue in general. Linus