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 EB0E9C77B6C for ; Fri, 7 Apr 2023 22:41:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5C29D6B0075; Fri, 7 Apr 2023 18:41:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 572616B0078; Fri, 7 Apr 2023 18:41:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 43960900002; Fri, 7 Apr 2023 18:41:13 -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 2EE2A6B0075 for ; Fri, 7 Apr 2023 18:41:13 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id F05B8ABFB5 for ; Fri, 7 Apr 2023 22:41:12 +0000 (UTC) X-FDA: 80656067184.10.6A4FBDD Received: from mail-yb1-f174.google.com (mail-yb1-f174.google.com [209.85.219.174]) by imf25.hostedemail.com (Postfix) with ESMTP id 3CE8EA0006 for ; Fri, 7 Apr 2023 22:41:11 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=bGGoxqFF; spf=pass (imf25.hostedemail.com: domain of surenb@google.com designates 209.85.219.174 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680907271; 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=ymBhYtC7z9ypgBt5ldvEEZjcUfyBTAIyJMw7aG6sy7M=; b=szWdPNRDxwQaaphp1RxEYN3pvpPf9jtr7UQpbD9WpsnOY8TyJvHjaBPbRh6kN/FZdUO7Ok jHQkrUoNW0IqG7hSdmEsKIUhT/xSSZvpCvHLEnXTJYJ6nhnMh4yZku9VPMM/dXBAQTMD5N feGUn24v0+PDwGPxEAiUrCtEuz4mxTA= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=bGGoxqFF; spf=pass (imf25.hostedemail.com: domain of surenb@google.com designates 209.85.219.174 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680907271; a=rsa-sha256; cv=none; b=x1nPUqm2dyVgjzeqV0sIYm5t9l161RHjtElbU7+lYSBiKgc70brDUO6LttyNMTgKu2f0h9 gVUy1VVm1wzf5N3cE7f3m2sasPans3yaOKd5VMgwBkUrFzgsQT847QOWC4gADAUr9OyyRz NbwO3Ds8eaC6HfGvHpmkKEgMQ7S9IfQ= Received: by mail-yb1-f174.google.com with SMTP id y186so50589yby.13 for ; Fri, 07 Apr 2023 15:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680907270; x=1683499270; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ymBhYtC7z9ypgBt5ldvEEZjcUfyBTAIyJMw7aG6sy7M=; b=bGGoxqFFQbRUS7GxiTztJ5wEKjUi2K/Pqyh5e41hyw0iSLKeNxU+tiuTVqes0/wgKy VggOgPNnT0/MvQKuQI7H3/nC2AFY+CQp1M1DVXtokamNaKfwmwQe5KM9PxrVMEcmJrXp Jp9d8gNPFKFaBzgNgixWqeNJsxh700MV5lad5NcLZLPGJDYzA6ugk4Rb+VMFlIIiQ180 qj31GYZnq74+1iT8d3FhGDurwrRTtPDr+gjDTrNn+N0lmxBYn2fX8k9imx6ZRNJuyfTM zQ756WNP3qm+p1sNIn9B4Z+wAYH3Na1dFtZClZDJmj5a8xB/6R4qRK1c4JnUxdE/1dS2 pzNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680907270; x=1683499270; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ymBhYtC7z9ypgBt5ldvEEZjcUfyBTAIyJMw7aG6sy7M=; b=suhrYNEWuAfZnaqAtXrplq8r+wrD2x1Vem8qhA6xHsbDp9Ou2fIAGQlXjrfomJkrH0 TfV9LGGyqjZq6FhVvOAx8LX5VLIHBTZGnQbGm+Cem8D5KwKqeCA4LuV+FQjSYXZugNzm 0OpeT/+tL4UFv7d0PVPaF1YBIepEJok0a7u6CoIfFDv0LRQnj/Kk+kVId3tzZ9QSCf1G xCjBDDUwhw11lfFigJT6Sv3j8jrkpalxBzz/dlYI+7PLJIKlFv5BBJjjXLG65XY42r5b 9rHoOTW7eA5oqYRp3/Ddhd3mSA7JMj2Doq0xGU0fg+cQUZWEb2NlrbNHA2iG5UwWqm90 uGYw== X-Gm-Message-State: AAQBX9cvg0dI81zUEt+IGKAtqFtZql4+XUcK/XCqQ7sicFeEneTbMwLI kwUt6iiWwuZihzUhUFbTvQmVYNDdMkipq7nhX5T1Awp3giai4nk6RSjbyg== X-Google-Smtp-Source: AKy350aTYlRzklvNu+FcXRnIY2yPIabbk15C/PoQAsy4KuWRicgN97axaEqbH1nM8iV5ut2pRiajDUns3y0soTiuGRA= X-Received: by 2002:a25:76c6:0:b0:b8b:ee74:c9d4 with SMTP id r189-20020a2576c6000000b00b8bee74c9d4mr2700149ybc.12.1680907270211; Fri, 07 Apr 2023 15:41:10 -0700 (PDT) MIME-Version: 1.0 References: <20230404135850.3673404-1-willy@infradead.org> <20230404135850.3673404-2-willy@infradead.org> In-Reply-To: From: Suren Baghdasaryan Date: Fri, 7 Apr 2023 15:40:59 -0700 Message-ID: Subject: Re: [PATCH 1/6] mm: Allow per-VMA locks on file-backed VMAs To: Matthew Wilcox Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Punit Agrawal Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 3CE8EA0006 X-Stat-Signature: fefg8rxu79rn8buzy7s73scc6ti3kchu X-Rspam-User: X-HE-Tag: 1680907271-168824 X-HE-Meta: U2FsdGVkX19/L/oO3IGcoZYXRkk2+oYr258QhyxpUo8rwilIa3H6y+L8zH68nbOBkL1/voN0X0NHs/WB+KAdVwAjbmHQNLiSbxcLebyaxzh+8FXQi/+bLhHXPovBQ54p+QQPBvT8nMRYa4tdVYpcsxGQWiv5Z2XSkNwT+512SttcTlBESf5pJJuK3esdq+N6sE8VRVuIPa/BQFkj+MvYPR6Rm0FVbKYKqxiu87Yip3YWvWBXkoyoStgXpB3V4g1wIYm+V6n6seVSDGbI7qHzcMkibT6wOBLbYNhFQe9MULtGtWDV7517OWwj/cZ5AIlyNIkZDiL0jlst1r8TroApj4jNTi9xTN+P1gVo1z8cjLHnECLB16XIAWnKHrhXlG7dPuIm/Gd6p5SsiyYZxl8LXzVvq01EcAkaN0fhz3bzIrxTF5t7Y2pnLVBUQ+xBLU44D8XsmTnSXKBKm2wB7QKclkJZDm2VO/QXjfrLUDyFYHkwfZxSANQuPjEbP9xWex3PeX+A+EaHiCgDEHyH92CVQtq5Mp0HOkRNXKWuflna0yk0Xp2PYOmr4zgPXKmzpXry0fCTks44AycSoIaye8cZmjxiozCcOrbZWp9Wkg6O6ZjdUVFMOflBQoHPEgLNyplJHEVD5+LPwCd7iD5A3G/nlcHQn/E3t8/jUq+0oOfWHWeymXLWbaWzOdAyvfSrSI8jGNvcPk4CUBmd6smYEIICu9xt9bc9qmJmFPujotl+PV/WiwfpJUikqnPiT/K0jSTIVfm54jhPhWLJ5/PfWs5XBi/cvKhYPkyx4IYLNJVnpxf2IeLnJN/m9cEa+XLY3256lthw5y6VU84DsMqjt8eJSTyAHikeWbr1KxlmF7gajPxzK5siy+qNf4Dkn2RuUSPi3emlRa1xAob9F1iLGHXb8vzDni8aNvU2o27dUah6uRhrjMaJO9VB5xYJjWKn8EBtfL5XEwo0qVhBc1qva+d uMpuy0tx LDHK5BpTBQXF6s5+RKUxPXyeFpR9VuDBH05K4KWNiZFhHFn1kROdhRFGOjnLbxRcme6glMFHe82YIAd47zsl6NQXBDGVcvtNLA7Om2SM2bBO4rfZxR5LwhQ/h5Yrtmgk3a8uYClN10ZISJTSKsU0yFJElkBJyevfbkiFDjIPmq/VfkgJqj9UhZUoHNFic55R3N/ectFKlsl9JuMzrM+OYujSJFElPpHJ59slDHFcaxoF1Xy2j6QPho178L/I+9p520K7pW/qJL6uidtbo4UloCIx/yYFx/FMRfCPCOKugW2Zet4U= X-Bogosity: Ham, tests=bogofilter, spamicity=0.001244, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Apr 7, 2023 at 2:36=E2=80=AFPM Matthew Wilcox = wrote: > > On Fri, Apr 07, 2023 at 01:26:08PM -0700, Suren Baghdasaryan wrote: > > True. do_swap_page() has the same issue. Can we move these > > count_vm_event() calls to the end of handle_mm_fault(): > > I was going to suggest something similar, so count that as an > Acked-by. This will change the accounting for the current retry > situation, where we drop the mmap_lock in filemap_fault(), initiate I/O > and return RETRY. I think that's probably a good change though; I don't > see why applications should have their fault counters incremented twice > for that situation. > > > mm_account_fault(regs, address, flags, ret); > > +out: > > + if (ret !=3D VM_FAULT_RETRY) { > > + count_vm_event(PGFAULT); > > + count_memcg_event_mm(vma->vm_mm, PGFAULT); > > + } > > Nit: this is a bitmask, so we should probably have: > > if (!(ret & VM_FAULT_RETRY)) { > > in case somebody's ORed it with VM_FAULT_MAJOR or something. > > Hm, I wonder if we're handling that correctly; if we need to start I/O, > do we preserve VM_FAULT_MAJOR returned from the first attempt? Not > in a position where I can look at the code right now. Interesting question. IIUC mm_account_fault() is the place where VM_FAULT_MAJOR is used to perform minor/major fault accounting. However it has an early exit: /* * We don't do accounting for some specific faults: * * - Unsuccessful faults (e.g. when the address wasn't valid). Tha= t * includes arch_vma_access_permitted() failing before reaching h= ere. * So this is not a "this many hardware page faults" counter. We * should use the hw profiling for that. * * - Incomplete faults (VM_FAULT_RETRY). They will only be counted * once they're completed. */ if (ret & (VM_FAULT_ERROR | VM_FAULT_RETRY)) return; So, VM_FAULT_RETRY is ignored in the accounting path. For the current do_swap_page (the only user returning VM_FAULT_RETRY this late) it's fine because we did not really do anything. However with your series and with my current attempts to drop the vma lock, do swapin_readahead() and return VM_FAULT_RETRY the situation changes. We need to register such (VM_FAULT_MAJOR | VM_FAULT_RETRY) case as a major fault, otherwise after retry it will be accounted as only a minor fault. Accounting the retry as a minor fault after the original major fault is technically also double-counting but probably not as big of a problem as missing the major fault accounting.