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 2FDA2C369CD for ; Thu, 26 Sep 2024 12:23:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 935206B0092; Thu, 26 Sep 2024 08:23:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8E5536B0093; Thu, 26 Sep 2024 08:23:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7D37A6B0095; Thu, 26 Sep 2024 08:23:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 61E236B0092 for ; Thu, 26 Sep 2024 08:23:10 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D14631C72E8 for ; Thu, 26 Sep 2024 12:23:09 +0000 (UTC) X-FDA: 82606804098.29.25648A9 Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) by imf25.hostedemail.com (Postfix) with ESMTP id F2710A001D for ; Thu, 26 Sep 2024 12:23:07 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Amt+/T/a"; spf=pass (imf25.hostedemail.com: domain of adrianhuang0701@gmail.com designates 209.85.208.51 as permitted sender) smtp.mailfrom=adrianhuang0701@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727353326; a=rsa-sha256; cv=none; b=hIfvt6+ceKIiW8YlCPR5MUK63K+tnFdr0KuUVhbsSeMA11u6tG1K61BSJFo0BJY+rDmOUB 3glTf451aTWbvoZj0kYEaoKtdFGfdWnIFxx1bJTunuRNodwruFH2RCGorBekb0HCCSrTv7 kzIPm8BrqDwmRRoRpySz7AiNS9rYgbM= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Amt+/T/a"; spf=pass (imf25.hostedemail.com: domain of adrianhuang0701@gmail.com designates 209.85.208.51 as permitted sender) smtp.mailfrom=adrianhuang0701@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727353326; 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=OOtAdGSLmtU0Tl9JOnUIzkV8dLA7+CwP/jLQK5eAiLU=; b=Yx8iEBOxUMPYJvgTndKDcVDuHhMnXfCl4Ki+0PcmkKv0wqQlMkKn1Md7bX65nEZLQHkVd+ qdvQTvAGgODM3TCPJKvn4SHnjT6ldZzbYWj5131EHEzuWyESF0qNOSWWtOwHC2MCbHX6ws 0Ll02kVPRxaY1vTh2I9ZUBeFtrNLicE= Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-5c241feb80dso3673732a12.0 for ; Thu, 26 Sep 2024 05:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727353386; x=1727958186; 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=OOtAdGSLmtU0Tl9JOnUIzkV8dLA7+CwP/jLQK5eAiLU=; b=Amt+/T/aUKGVNls8BHqiTjOYAf1AcYZlI693Eiz1sSVBWiCUpkdc3p3XOQnTMDlmL1 0aobYHKfVSb3xLx8CLVLHj2qcIPejXGZSbU5gif1nE2GQ/9o9ECShU+Uv4wctFOgrsuo uqzO0gAQWHXvxSed46ndvjgKHO0jipPf+h5bogmYDcc5NCGPi7f688dSDXzIPc56SoaD vbJbDlHA9KmWJmdHCLfi41qEuhtTPodb4GfTv4SNgarGLTIz9vnTkctBygmlzQIVX7VL MOahoryJNASXuWOdojeB1kNqhxQMYjtZVBPWg/p+Kp3WIcJH5N4PQMQzIBglsCYblV1E i/4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727353386; x=1727958186; 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=OOtAdGSLmtU0Tl9JOnUIzkV8dLA7+CwP/jLQK5eAiLU=; b=eVrv9xgMby/thXF0X7TR+kP45do/ZbISBnRm2GVD3XdpvJ6UHnjgGmiDzKYC9Rxacd XKuQ+p26m2UQlhpudSpwsZHtqs28dhOWBWlEtQyCX1ut+VxvayemlNuXk0eqI33IT2fK tHiB9e/rhax2NzGWH2+NRaB3uunysxsWHEGHRzLdFi9CjYHVoG3x4ERFFelyE/6/wsii LKTQ9GCuFQ6+mlA9AYekWdcRAdhBG8iRtYh/Hw1KDFAx4eSAbZ2yyJCEq2GRjTG3/ueU iebDaTyUZ3yr6AACYIl513DuehIjI5RXli4o5vkliYAcdIfDOBHSEsyf+63T/k93PUmh A7Cg== X-Forwarded-Encrypted: i=1; AJvYcCXHtOEmTFI8QjVJIJ1CS4AReJi/fXU0cZpkRzaQt5cB0rM+iA20jj55tMT4iUPOhSDaEXfdMNKjyw==@kvack.org X-Gm-Message-State: AOJu0Yz39ZoDeGYdQVBzdhmsU2pnriP1xFlwsqhwAYaMRedCGxbLW/MG f89XXYKqTnMZnwNMOPy7KL+N7cPq2BBMj2ZShEk5xFIjIYrSgzQ17a664SmoPGdMxstYBMkD4eH WRWZPANcw0n8u3FMhVmQxlJcPUhcHwg4uYNg= X-Google-Smtp-Source: AGHT+IER0I/Mcrqs3P0SR1Afg5c32qaZvfGnypuc9N4ejqf4RJMfQxSgsS2aY5Ti4IQH0claNSiUXpiO6MeuC7PgVaw= X-Received: by 2002:a05:6402:40d2:b0:5c7:2209:dedb with SMTP id 4fb4d7f45d1cf-5c8777b59c1mr3107804a12.8.1727353385705; Thu, 26 Sep 2024 05:23:05 -0700 (PDT) MIME-Version: 1.0 References: <20240925134732.24431-1-ahuang12@lenovo.com> <20240925134706.2a0c2717a41a338d938581ff@linux-foundation.org> In-Reply-To: <20240925134706.2a0c2717a41a338d938581ff@linux-foundation.org> From: Huang Adrian Date: Thu, 26 Sep 2024 20:22:54 +0800 Message-ID: Subject: Re: [PATCH 1/1] kasan, vmalloc: avoid lock contention when depopulating vmalloc To: Andrew Morton Cc: Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Uladzislau Rezki , kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Adrian Huang Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 449ss7raejwnp4x8dw3wpd5ofy4t3x3r X-Rspamd-Queue-Id: F2710A001D X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1727353387-560790 X-HE-Meta: U2FsdGVkX19mZyoDWQrZ2kVIJqvbTs0Vp7DE3i7C/t20HvaLEBhEDLJTJrswIUsI6G3ffBncm2OZVWiYVDEyV61nMxVBerr3/iYFijfA/8Ep/K/1y0XmPRdFNhh5PS5MTw2NRCaG5EktVeuMTuDDH3iqwWMB2Nb5lg16Z4S6KUfLZeS+i6Sud1bxrkXbkjGtiNk4LJ+0kxsqFS+SAOTtaP5gNrE14gqZVlTU5RJKyV4/81fd3Yh61B2GFJuu87hEnT7gXLty1Bv64uSwj4Ud4lAPDt7UDrn0fQ1vQdTx/lwzcmdPZ66ihug/1PxNRgAs7NIBsvfuUnYY6p+9MSp6KzVKpf1hfAJ+j14AdBzm6inp0yqb4t87giUxKCzIAeVoCbDYqnp0p3qMoFTXudRXGN1WfURFAcrlHbNENdXJgs/gWg+NIENAu7K8S3asrq0B+lbWSc+44R7+H6RyjQL4PodXan0RzDcTnWKiIeWTRdASF2yevRmc+HA712z/rm4OBKnbaMMVKe40h7+iF8QMerYlSgu4EIsQhyN43L7uEr9qnI8+5q/zHMbA3vPbvANsX0rw6edKmFVgpOsia3K6leX16BSGyXW+pBB52d0WI9YjoLJdv2/VH+YezDqqPLpZGvyIY+0IY4LBjEWmYHChUXR2GnBh6tswCusAPOfV7IBNDZQqzNH2K4EaIT80h+Suz6dII/1lJh6qHlItRCxOR7xmLVerzZqKtjYzYZBbrHWJbLnFhF1y/QhNmgvLbDa/LAbN7zNRsHrRCpu/ID9GsB1HFARAkpE7Lzj3bOxwCW4dhk1BEs3QMvT/9Rr7jaYrfOEs7sp5gCaTF3xrabpTqf98lDXXXUB0sogE7Pe6aPp9ac6wqanB6XRpmoSmT1AlCioeKCP4xSTmuBoAsZjnkZJay5cDN6KmIHJF8G9vJPK0hhuKnRAmyV7J3UTJEOy00zEx+e9IKkw0sJyGLPJ BXoqoYwK d/RxN3hOOPYkMd3H6h/xArczckAMjRDbffQzPLuDgBQkO6HiYhSTAnDeqnK+h3fH7bY0jZ2xDS6yqYSTeykgxKz+k+anNaZr+5nTnQ0DT3/x6hSKOVD2+vXJoUjmS0/S3KhsVk0NPYg0hmZN4I/xBVVAYEnVdKHrX6NIMoZFgT4LeuFEWu89jv3MMyJJu+eXuIRIxzNPAIJFlCUyYz17gk1MBdeiGhbKxU1DUFNpvxEbv5P1+qsVVdRwnhLhx+mMy0R/y8Igk8fFRxU6Sa5D5lhoiZeMzCE0IWQlnEhaf4WnBXWcdNLu/nTwvZYAvz0aqlzd4H96kUBBHIZ6gazaVISpFOQERp+a7OJfq9ZLk0gDBFoUes/+HHladDMkb4h8iwiuu/lsXKCH32zkPSQySHqdOnS59lrraH4CnaAZFfchNCNMJAyWDgZ2YJcuhMH0HgfeWbYx5u0Vv6S1whWEdca2xA5nMj6+LSoFdYqXb/CKrGaR9CCaERDIIzw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000007, 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 Thu, Sep 26, 2024 at 4:47=E2=80=AFAM Andrew Morton wrote: > > On Wed, 25 Sep 2024 21:47:32 +0800 Adrian Huang wrote: > > > > > ... > > > > From: Adrian Huang > > After re-visiting code path about setting the kasan ptep (pte pointer), > > it's unlikely that a kasan ptep is set and cleared simultaneously by > > different CPUs. So, use ptep_get_and_clear() to get rid of the spinlock > > operation. > > "unlikely" isn't particularly comforting. We'd prefer to never corrupt > pte's! > > I'm suspecting we need a more thorough solution here. > > btw, for a lame fix, did you try moving the spin_lock() into > kasan_release_vmalloc(), around the apply_to_existing_page_range() > call? That would at least reduce locking frequency a lot. Some > mitigation might be needed to avoid excessive hold times. I did try it before. That didn't help. In this case, each iteration in kasan_release_vmalloc_node() only needs to clear one pte. However, vn->purge_list is the long list under the heavy load: 128 cores (128 vmap_nodes) execute kasan_release_vmalloc_node() to clear the corresponding pte(s) while other cores allocate vmalloc space (populate the page table of the vmalloc address) and populate vmalloc shadow page table. Lots of cores contend init_mm.page_table_lock. For a lame fix, adding cond_resched() in the loop of kasan_release_vmalloc_node() is an option. Any suggestions and comments about this issue? Thanks. -- Adrian