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 0B0A8E7717F for ; Tue, 10 Dec 2024 16:26:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8283A6B0250; Tue, 10 Dec 2024 11:26:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D7CC6B0251; Tue, 10 Dec 2024 11:26:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 67B256B0252; Tue, 10 Dec 2024 11:26:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 3F1636B0250 for ; Tue, 10 Dec 2024 11:26:41 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id D467080774 for ; Tue, 10 Dec 2024 16:26:40 +0000 (UTC) X-FDA: 82879577340.04.9446712 Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) by imf17.hostedemail.com (Postfix) with ESMTP id 46A6D4000F for ; Tue, 10 Dec 2024 16:26:22 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=PLH6x79s; spf=pass (imf17.hostedemail.com: domain of surenb@google.com designates 209.85.160.173 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=1733847976; 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=hLfNDRBixJVwXkZBjvzOyN3fdyshtMbByJWJLFYkJ5g=; b=laeB0qQHjEFgWOjTZUBp4ZFQy3EWulLRrji3ZE+4PZAsYqSSjz9ETt6hKG4GgMlIIT+1YX PzPaLlMCIbR9GN7L8xJuJjW9iXzMs0YREvvdgWlvMi27z2WXQO1WOo+8NUsYnzKTo/z8+k W8uD2ZK6QFSGkSxEsfLxjbIEeSJKSuA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733847976; a=rsa-sha256; cv=none; b=L0mNE/y1B9fd+OeKsUPdch7SgDoqtRCs9CEHM6f/uJvTKc8gTT0Yl0qmyvExhr/808heVv Z2Y9UfFHQQXhCoQhAqPyMKudpLKIBZwR9d0OBSF5Carl/IgM6c4eX8OvpYp4xxFHGd89d1 HHzCVTpVnOaUV2Owdmxz0aL4AN0Y5ys= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=PLH6x79s; spf=pass (imf17.hostedemail.com: domain of surenb@google.com designates 209.85.160.173 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-qt1-f173.google.com with SMTP id d75a77b69052e-4674c22c4afso300951cf.1 for ; Tue, 10 Dec 2024 08:26:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1733847998; x=1734452798; darn=kvack.org; 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=hLfNDRBixJVwXkZBjvzOyN3fdyshtMbByJWJLFYkJ5g=; b=PLH6x79sjcv0GaRKukenV3K5V36xmO+5Pz6jCv48nmAGrjrwuYrWaL9A1rxddPuvb5 dR1hFhioF9jljj6Ew+ZFIiMvLnsMTTWd2gCU2qRONzAVct9YNPa69eyXelW/UUJByaUG CCyKIUvjxCoczMQAbHpY3VS53zUC7/nOoO47GMvvVR7Y9ovYyz3BiMS1csOzFJwnni7x IesAwlb5T+T6zffHq8H9IGPSgtIyjAxTdJFlche5LatygeFEbxVfutb/UXNCsLecqD6T hm3hKP2V6rWiOmQTJPeHR0Bat3GhED7n0Zw6I8GAqZuHSan40PslZgNSALJH2MANwrK9 WCAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733847998; x=1734452798; 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=hLfNDRBixJVwXkZBjvzOyN3fdyshtMbByJWJLFYkJ5g=; b=tGDWEPEj79afc5q23UuPRRfU7dFXzLTJgzAVw/mzp9GeZweLLd6AixcQJackT0pHX+ OUTylud7VQZz7imtCeVxr+MU1IqgL8GDVWK9YITDLoGLOOCxqAwGT049y0eQjkX33SKo DiHx155BhZkUha445A5vE12L6BAikl5IcSZ3VYqrr7BsV3FRGvVdS2NPz1MjLp9H/yMz ZwM1H3bpyate21Eu+k1VslVXz9+UscKQR2WE7pLKT5zMlD76OAMB1IBfcggREGcZVwK5 xsBlp9qqy8AhGwr2ooeNcLtwAKohn0/mfItwAv9KCUgYrOuFFuAlOybloi48ldrb1mrb Aghw== X-Forwarded-Encrypted: i=1; AJvYcCW+z6MtnPtdkoiJ0CNe9L+/DLsy9t21kqsOsC6cGwODV9YLOGNZNrW7NimGmxV8nBrYNedGt5ZG+g==@kvack.org X-Gm-Message-State: AOJu0YyIFHtqqEE5dYe5xUMR1hUQl3rsTwjVsLmbF5b6UZBBgezmxONN NXWyoqWMx6a5Z9+OERkWQ3YfwTnWW3VGrvXb3iPWo7Lbdty9zXj7CN29oI8zQ/xofzk5z9N285x mrUXHRozsWD6Y6q8vecp9OY6I5fPePOZQaIDu X-Gm-Gg: ASbGncunvxuYlQyxC3B3K8mncp8donjDtlGbaQiZmXO/x2rTiR+nAguXkguVty4qnqb n3KAZ+tv9XvF4v6p+eXk5XTEh6j8Tyew2/RAoK5YCSwnW8ViwIPwkhoPIi4GRgDIWTw== X-Google-Smtp-Source: AGHT+IEGNVlwrm/5/0osSlNw9N5wYx2d4i2tGfaxKLisjegd7IRO6yWbSsGrIx+hLJ0crW1/0nDcw1Y+gDywI4ihS5w= X-Received: by 2002:a05:622a:550a:b0:466:861a:f633 with SMTP id d75a77b69052e-4677757cac6mr4012141cf.5.1733847997888; Tue, 10 Dec 2024 08:26:37 -0800 (PST) MIME-Version: 1.0 References: <20241209221028.1644210-1-surenb@google.com> <0448d4c5-1675-402f-9629-d1348019e38a@redhat.com> In-Reply-To: <0448d4c5-1675-402f-9629-d1348019e38a@redhat.com> From: Suren Baghdasaryan Date: Tue, 10 Dec 2024 08:26:26 -0800 Message-ID: Subject: Re: [PATCH 1/1] mm: fix vma_copy for !CONFIG_PER_VMA_LOCK To: David Hildenbrand Cc: akpm@linux-foundation.org, oliver.sang@intel.com, klarasmodin@gmail.com, willy@infradead.org, liam.howlett@oracle.com, lorenzo.stoakes@oracle.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, mjguzik@gmail.com, mgorman@techsingularity.net, peterx@redhat.com, oleg@redhat.com, dave@stgolabs.net, paulmck@kernel.org, brauner@kernel.org, dhowells@redhat.com, hdanton@sina.com, hughd@google.com, minchan@google.com, jannh@google.com, shakeel.butt@linux.dev, souravpanda@google.com, pasha.tatashin@soleen.com, corbet@lwn.net, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 46A6D4000F X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: u3br18h1isu3okxcuyi1bbku9marrgnb X-HE-Tag: 1733847982-874107 X-HE-Meta: U2FsdGVkX1+L/uEQzJ7Mawl4fsKVPcvD16GwgrnLEyNsKzmrDhLVFdsI3c2G3kfp66k9z8QfK5ljZ3h/NbELPshzyJJD7PT7IRZFeVVnLh4ZIpU5LyR1SPL6SLu9by3CzvbbskqmPjDA1221FqdJrmXqkRRkAiAlmJ0JWMP1tX2SKu+0LT4vGTCTOqOH+20DXSKklcB/k5ZsByg67kjt5J6ktqXi3x3ldgMfqRGmz+giFIZuP6DGOt7Vp0h610Iv2H/WxXptu2iLuFvAEq04m4nAK9g6xZkrlsN6QjRDakK8x71UCkgdWLt5JtEaOKgM889MQjm5TsjmIGRUdvR8TxoeC++3ckuKrA9RQ8A75/T3cMgBs+ednsnPJ83joygkGBTUYNHqdNLym/dNYysR6Ltjo5NGMe3KExfA5rsOqlFQtrjhNbhOUFRwx3igtQDlg+lcVdO6hVKy7JHwIyfCyJnF3ZM+IB+u6+xZsoMEK+OyrMjcdQQ5zPnw+dTBBrrjO8X1KEJLCb/LLqb/2jKxptE1KYDev2KTBdFeAljwy+iEM7KeQHhBW/zRc9GECag4Nysl1XQzwKGFMPWMlpl2zm5eHq5qkjXVp3WFEGQ7R1hdaOZvgi0+jsydf+JF9ENdBw5UHJO0A5YCef+N7NiT7NCvxKz/oJcUXhYicfBopn4IsYV9ZnRC2tZPDLzxl5YVK1hSwahNtNo3BEwiHRwxUS0X6ndzRuT59UvQkJdsWsREjZ+QFurZJOJza3ErL57iweubp+cxYNzqXYkW58nX9NUY2V6TfTxZ4RMEaevu/5DYQmByD3JOZ9NMS6HG4jlzQg03iN73XOfmGON54QRXsDNbB5jE1yIAOo0LoD1tBpQdNjvy9AGJZASSd2+r3cFug3MlFEy1cdayjot++Cva3drPdH/fllLH2GOHlBSZvloFJPS0nIGSjoS+8xUGZ434q2lsOiAt7+pDA6rT4ey ME7mDAIp gqZep+dUv8RNziEg/QBP8YqxWs82nn9a8MpE57YC4nF/90G1r1zB8pHsX1zrfWghp6ezlv1OOflzFDrcI6Q9WWCmUB7bHRSAoYaKbU8iM42cQeTycc3Am/oC4hkc8zjtQ7k94XvSUHM7DytIYzlIK6M90m2zNY925bZzYOn37UJHNBgXRCHeeFVOAdB+oGRfx+bD3siOopgQEtx3B6xfg/EWvagcjVqrZC+r7wdlmIGuQX4Tx7aFm55mqD8dyxzasOzq35qgo6x5GpRhazo+NAawvDJFpeJt/rksh7Qg4WzviwPTSesncZB81mg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.263942, 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 Tue, Dec 10, 2024 at 1:06=E2=80=AFAM David Hildenbrand wrote: > > On 09.12.24 23:10, Suren Baghdasaryan wrote: > > vma_copy() function for !CONFIG_PER_VMA_LOCK configuration copies all > > fields using memcpy() as opposed to CONFIG_PER_VMA_LOCK version which > > copies only required fields. anon_vma_chain field should not be copied > > and new vma should instead initialize it to an empty list. Fix this > > by initializing anon_vma_chain inside vma_copy() function. The version > > of vma_copy() for CONFIG_PER_VMA_LOCK is fine since it does not change > > that field and anon_vma_chain of any new vma is already initialized and > > empty. > > I'm wondering if there is sufficient reason to have two implementations > to do the copying. > > How expensive would it be to simply use the CONFIG_PER_VMA_LOCK variant > unconditionally? Is it even measurable in fork() micro-benchmarks? Yeah, the benefit if any would be tiny. I'll try measuring the difference and if it's not visible will remove the !CONFIG_PER_VMA_LOCK version. Thanks! > > -- > Cheers, > > David / dhildenb >