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 1A659C77B71 for ; Fri, 14 Apr 2023 18:03:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8E342900003; Fri, 14 Apr 2023 14:03:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 892D16B0078; Fri, 14 Apr 2023 14:03:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 75ABF900003; Fri, 14 Apr 2023 14:03:14 -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 6471F6B0075 for ; Fri, 14 Apr 2023 14:03:14 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 2DD86403C1 for ; Fri, 14 Apr 2023 18:03:14 +0000 (UTC) X-FDA: 80680768308.29.E46C785 Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com [209.85.219.177]) by imf20.hostedemail.com (Postfix) with ESMTP id 646A81C0022 for ; Fri, 14 Apr 2023 18:03:11 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=DxJ961Fg; spf=pass (imf20.hostedemail.com: domain of surenb@google.com designates 209.85.219.177 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=1681495391; 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=AKDw7OMIZVnUYlLnZnbeGeiBwQIxHaZo+ZsFo8B2vdM=; b=7ijUwz2kJtRC9KHCmhXVYuuITodqRMo6NVwJH8BvprUan+eHNaOPdrBR80cMi9S/p8cD42 CyZEAJzFJfHlOS4X+9Thmkuxrnk2+/UEgmrcWBNexbYSelxhbjeDGTv/Kyzup3rwcdoqEY Z93iwZ9lkyAj0RHExDwk8Qjd0pWM5Mo= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=DxJ961Fg; spf=pass (imf20.hostedemail.com: domain of surenb@google.com designates 209.85.219.177 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=1681495391; a=rsa-sha256; cv=none; b=RUjZ8FzKdRydPRabsU4ddHtZOAtafnaNphwEd3K1Onaxhansthfx6GUsnJ1YJI7DKTwlrT HBH+n6sIt7PyZBAl0kPES01rI19ehMrR/Cwb2E6iA8l8YHGs6SPYVvt/MvJ6MTW38FEQz3 gihkcNzoP+cdQH4MiRlV71kJDyVnDf0= Received: by mail-yb1-f177.google.com with SMTP id n203so7988205ybg.6 for ; Fri, 14 Apr 2023 11:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1681495390; x=1684087390; 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=AKDw7OMIZVnUYlLnZnbeGeiBwQIxHaZo+ZsFo8B2vdM=; b=DxJ961Fg2EXYXS9CDvA0zoP8ZcMkZEJ6MFIa0BvcGMWn+mABbL1vW6aP2hTrxy4Wzw bE3mOjku/Zd2hA84K5SrckCnV1dI7ZruOWw5FoEWmPuo7UaBQe1iLywqBPk+hmiUoS2w yHq/cS6GybVZNdlCt3XFNFexKej6lWkkCg+/5popkqmEbhw2Xen1DBodwZQwTN+cqw+q ytTU3j12sfJ1/04NcNaSmacUFSYssTmoAT3E+y9tcbM4OE5R2yjKNLcXnNi7KYNTjry+ xkBxUCCwehH8Ziu+FaQJMW/LSBBavsWhDStiQb6IbhqejCC75K5PIL8EkR7ytDvU9hFP lnBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681495390; x=1684087390; 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=AKDw7OMIZVnUYlLnZnbeGeiBwQIxHaZo+ZsFo8B2vdM=; b=LmjRhlsFaGDbvYVDGZYmKUBn7jHY+9DL7i6QicDQJbWuF/ddVwGk0kMdselfouGxSB sMUjyosAwOjceVkZjZ2c24rwu8X3fLX06RzyQLPS4rTZ/U/6jirq7d03aPbF8+7g+vgX h1I1JXMF8ilPIrBNXP3NrAQnbbMAyjz1Fb5YV5AIa1+0w12tOc/ej1GtTis+Yh+IMqNJ T7OTPz8CE0dFZkQux/RUFAZe6F7cxahAwQ5FRUT1pRAVgm/TxASJ750uIAjE8Q9G13vw BM66Odv6yNnp9BhyuBYfq7+1fqE1vF/MFBrSuK9wUIQm5ujSOmzHaWMr5N1wvcAmiuwz TXTw== X-Gm-Message-State: AAQBX9fbHpw+P5AMi6btEGZkrGL3+9gWMIhWXkelPuEByTwO9BGzsSsH MYJvxy0qWGiH7gVYqvovIYrC1d4oT0xsxRpYVy/yJg== X-Google-Smtp-Source: AKy350bgZ+8bUqtU8jUmvVI6chm9ORr6sN6LYpcmHD2Xf4VoanUico7K7J1M4W+lBXqwKX05ITd8KR0i1nnlwdxg0c8= X-Received: by 2002:a25:7602:0:b0:b8b:ee74:c9d4 with SMTP id r2-20020a257602000000b00b8bee74c9d4mr4335988ybc.12.1681495390240; Fri, 14 Apr 2023 11:03: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, 14 Apr 2023 11:02:57 -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-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: 9u89j3skpt9i3wzieqf9jnsfheuwiha1 X-Rspamd-Queue-Id: 646A81C0022 X-HE-Tag: 1681495391-547689 X-HE-Meta: U2FsdGVkX18OTT1yrkg48x/Pt/g/QeKz7vLry9wk5RdLJdY3O4HCi80Ct7yLZQHGsQzplnmV/H+lo8laC3S6hD2A2JzEKXKQvf7KSXY/bN0eQ2HG9hzTq2MJZGlpbRJak2JQplx1clgy76GfgpyqXZCQljhxOK1hmooDEp3w+EtGGTGpwbbWEAmwSs3hZxct2adyEEO0r7h5NbBnHsNKc4wPdjqRxcLFu2O/v2Lh5JhVuWSXxWzkmqE96cQEN4ewwZeDN/mzPtGZK1GN0wCotDeYHLDdffTyIAUvTaYE8zMf3uMSJiw/mCu+vwSzFddbp8Vk44g0XaQK8GBDz+FFSmSQMrf4nC/h5eN5gdbI6THK1/whVotya/3XK6SizZY/t2qsK8TO/J5VStO4mDZNeGZ1IgsQXMG4zc/+1DTyvT34vqZyho0cEwtcBd4uGWgGVEWLodk+bwh4pHUdgPK05Zj0imL6yghspO0l52N58k8vN2o0lLiYOawatYHXXn8xHu2JbUEd4KKy/KTFWZLMTp9QxOQ/0UIyW7+aPlMg31Rae0RcFaLtWfDEXKLhLQnjqNiouJz9irm4w1CCqa2Ckdyuh/P0LSB1+3YBOG05AF5MnLTnQi68xBse12gnyJCEUY+TRvHzuEtzHJZPqQZYh1RJejxVpCx5O+6r8ztEnFZzIau4MS4fQev1lyac5lHkEOU41EV7JCRmn/h0RZum9I3OyXVzzrd3Gylgy6RephFCaxpPHZitVgp413mJCIlXml7E7DI753FE+mqCpUMLZoH1V8NN6WXvjG2/ywr59QkgT5W0lutfwshLVVAypefMqwsTSr3JoCl0vueN31cag0SvsYWOLKD9opN/npzbCB6fbLyUWPn2+Lo6SgnuTAsY4jbdtdeLAs2MME2M9mB7+eevlQeHdX6jQaUZuDOIlSfjJnmcSoRCqfcebPkArfZr91WQGHOdAQRurRvTStJ mllN+kNS x/p/5Lf9SpO1efmDdxdaCc2WkI9n634XzgdagKwQMMYYO3DJ6ReFQ1OYqgLPYIow8nCUQ7JPwTlmrGAYq3/u+E3W+Dm3yERTiXisBdkfCtdyRspPWgKrMChikC0anuNyGBIGeXWCCjfLo1sGF2RjlrXztuIgwvr0vEpbgck4yvA6JTkU+/ekcxwLsh2r2WnqAp1Iqo51l+I/xfjyCjAu8PL0C5cFcE6scGluTsbC7WNw0oPozO/f9gjaIDD5JuGOMJaecR/1oQK2+By2kx5XhQQuSqF9rB/FjzhjwVgMrQtPRxHLqWXi1KET61rt1t17k32peNG5rYzlOiiemJeSAn0UmU8Oc+1GZRxV8xjLfbPMEvT1dC5OkL7V1UMFJTqb9ubyw X-Bogosity: Ham, tests=bogofilter, spamicity=0.000013, 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. The fix is posted at https://lore.kernel.org/all/20230414175444.1837474-1-surenb@google.com/ > > 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.