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 92AEEC433EF for ; Wed, 9 Mar 2022 00:22:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1DBFF8D0002; Tue, 8 Mar 2022 19:22:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 163F58D0001; Tue, 8 Mar 2022 19:22:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 02B238D0002; Tue, 8 Mar 2022 19:22:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id E34958D0001 for ; Tue, 8 Mar 2022 19:22:55 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id BB36460365 for ; Wed, 9 Mar 2022 00:22:55 +0000 (UTC) X-FDA: 79222947510.10.E074B6D Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) by imf18.hostedemail.com (Postfix) with ESMTP id 2FF911C000A for ; Wed, 9 Mar 2022 00:22:55 +0000 (UTC) Received: by mail-lf1-f44.google.com with SMTP id n19so893328lfh.8 for ; Tue, 08 Mar 2022 16:22:54 -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=yOkhTNcLWPufcykwdZmZBF2oqQGok/K5B2vr+Tqh36g=; b=Vj4rshnTpWz5DU66OERET/pAsAiEtJHCvq1p7tYsuGWD7WJCMh23fM0fO4nZdPLYHC 90pf8J0GgnEP+YZrzPyFs7Bg/J9pen3fzwCfz2wTn/gw4B+2lcPdZNWYCNfMWKpUwV9E ohAJR1uT0oUJ+kwVfBbrRuha/QYIMA/OMi3B4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yOkhTNcLWPufcykwdZmZBF2oqQGok/K5B2vr+Tqh36g=; b=HqivqwOoCeiggLME7GPxQtUi62ovq0zhTdeVED+F6I/nBCZP4h2+khQ6YtGIpJjTZy QOwvC1I6A82EXJYRUJ4ELFHLmmPnfXmnXvZe3TVrZ5iqERSAOzCL3kUVUyFJFLSzrCkT 0OIg/aoF4+pnlPebB0A3KEwpe4aUykCulDOT+Xs0MNTVjjCbZl5LA462lZWtTvWf48mK 1BIx+8z7QyxTmsJA9S/+CCf6OSV8AEkMAZkIwNfh2NGCnyBnv4IvPCBvyURfuzBOrpa+ 7k4O9A9XzYtXSmOJwcvj0g/wrL7QmaT96D8TAWyxBhagvMaevc8zaHnOEmRk83DIJuHq rfaQ== X-Gm-Message-State: AOAM532fQ+7xW011RLCsosCy1kwL1qVpD0mlF2DeRzEgouBGiFntXtyX +DZ/6STdCxePlnki8eS8X7YILBRQo7ZBR7YwybU= X-Google-Smtp-Source: ABdhPJyPW0QK1F4mvmwdWmcGY31CYyYgrC3tV6IeJIFTrOPTQ4kdLD8RrKQRK5YZkLYWJEljy953UA== X-Received: by 2002:ac2:530f:0:b0:448:324e:3c29 with SMTP id c15-20020ac2530f000000b00448324e3c29mr6729736lfh.160.1646785373220; Tue, 08 Mar 2022 16:22:53 -0800 (PST) Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com. [209.85.208.176]) by smtp.gmail.com with ESMTPSA id q15-20020a19f20f000000b0044376b4e80bsm65488lfh.279.2022.03.08.16.22.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Mar 2022 16:22:51 -0800 (PST) Received: by mail-lj1-f176.google.com with SMTP id r22so886330ljd.4 for ; Tue, 08 Mar 2022 16:22:51 -0800 (PST) X-Received: by 2002:a2e:6f17:0:b0:248:124:9c08 with SMTP id k23-20020a2e6f17000000b0024801249c08mr696937ljc.506.1646785371366; Tue, 08 Mar 2022 16:22:51 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Tue, 8 Mar 2022 16:22:35 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Buffered I/O broken on s390x with page faults disabled (gfs2) To: Andreas Gruenbacher Cc: David Hildenbrand , Alexander Viro , linux-s390 , Linux-MM , linux-fsdevel , linux-btrfs Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 2FF911C000A X-Stat-Signature: n1jezjztkp5bqh5umwhgui7cwaqrajxa Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=Vj4rshnT; spf=pass (imf18.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.167.44 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1646785375-872665 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 Tue, Mar 8, 2022 at 3:25 PM Andreas Gruenbacher wrote: > > Seems to be working on s390x for this test case at least; the kind of > trace I'm getting is: Good. > This shows bursts of successful fault-ins in gfs2_file_read_iter > (read_fault). The pauses in between might be caused by the storage; > I'm not sure. Don't know about the pauses, but the burst size might be impacted by that + const size_t max_size = 4 * PAGE_SIZE; thing that limits how many calls to fixup_user_fault() we do per fault_in_safe_writeable(). So it might be worth checking if that value seems to make any difference. > I'd still let the caller of fault_in_safe_writeable() decide how much > memory to fault in; the tight cap in fault_in_safe_writeable() doesn't > seem useful. Well, there are real latency concerns there - fixup_user_fault() is not necessarily all that low-cost. And it's actually going to be worse when we have the sub-page coloring issues happening, and will need to probe at a 128-byte granularity (not on s390, but on arm64). At that point, we almost certainly will need to have a "probe user space non-destructibly for writability" instruction (possibly extending on our current arch_futex_atomic_op_inuser() infrastructure). So honestly, if you do IO on areas that will get page faults on them, to some degree it's a "you are doing something stupid, you get what you deserve". This code should _work_, it should not have to worry about users having bad patterns (where "read data into huge cold mappings under enough memory pressure that it causes access bit faults in the middle of the read" very much counts as such a bad pattern). > Also, you want to put in an extra L here: > > Signed-off-by: linus Torvalds Heh. Fixed locally. Linus