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 64B15C02181 for ; Fri, 24 Jan 2025 16:31:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CC99E28007D; Fri, 24 Jan 2025 11:31:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C525E280079; Fri, 24 Jan 2025 11:31:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AA60228007D; Fri, 24 Jan 2025 11:31:58 -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 88EE8280079 for ; Fri, 24 Jan 2025 11:31:58 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 0CC9214148A for ; Fri, 24 Jan 2025 16:31:58 +0000 (UTC) X-FDA: 83042887116.20.BFA7710 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf29.hostedemail.com (Postfix) with ESMTP id B9956120003 for ; Fri, 24 Jan 2025 16:31:55 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=PdXuN8hN; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf29.hostedemail.com: domain of vschneid@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=vschneid@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737736316; a=rsa-sha256; cv=none; b=Q1mVq6GuXAFQG1dp/lAgP02Ue7R8+4nccxPndouPrWFA45I9X02Z9wCpsAg9aaDoUOgT8J pW2kDnQArG7KP1FRUsndTfOzM5Kkh8HQH1JmRoBHOAHCpZ4EmnCuf1Dr3+K6Bc4xfguQDH 0pNDY0fAYo1gUVAmJKXUSlpkI4u6nUA= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=PdXuN8hN; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf29.hostedemail.com: domain of vschneid@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=vschneid@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737736316; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=DwitzjRGQEzgyZZn0UD4LNiBUZsqGx1Qrum3CBb5LtE=; b=6u+MhTrG9/0Ru6DDSaXaDjKZSAgsjFUM3md9FgdS4iCQ6t4oKifhUoIa6N4iAvWab8s4Z5 zhuzsqy/8riUlKULFjRVsVU8gjd8/pioRQt2EihqdKEuEh89XCSDs842+es2hjhh7MmpN1 uOwPC+Wht06iW6N6CyGtuEaBcswdaRI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1737736315; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=DwitzjRGQEzgyZZn0UD4LNiBUZsqGx1Qrum3CBb5LtE=; b=PdXuN8hNks1GTmLs1ftE7VYdOSA2DrPsWYSXuGJ/6f/DL8Q+XrfoEVpACneRrZuOwo/w9G pexvGu2tLnFRjP1XinAI97dSOGLMsDqv/U0F4jcZ6hej1aB7SCPOatxX5GYIE2fouQoRXg 0G6/hw0AOwK+cVIfTRRKG1xEOkHAaaU= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-448-aF2bpp3rOpyYhKgRsqltgg-1; Fri, 24 Jan 2025 11:31:54 -0500 X-MC-Unique: aF2bpp3rOpyYhKgRsqltgg-1 X-Mimecast-MFC-AGG-ID: aF2bpp3rOpyYhKgRsqltgg Received: by mail-qk1-f199.google.com with SMTP id af79cd13be357-7bb849aa5fbso514587185a.0 for ; Fri, 24 Jan 2025 08:31:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737736313; x=1738341113; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=DwitzjRGQEzgyZZn0UD4LNiBUZsqGx1Qrum3CBb5LtE=; b=WPerCO/YnIyYa1uE+PlfcNKeONX+ABfajaiq5lXM6lz3uzMPN5uTtdijJJtbtHJEQ1 WALQMqvK9IHr2M47XEOeriCEz5ixsmDr6Is2n+15VZJybuYTgxgjClAhVE2cIo6cgGyp kChoVo62v5uK3rvx0/Nj0pU/hyJBTEVOW1AP4IHfjKd6oVXelj/SQ19V6mMaUZsrX4+v tHhUN2mjgmGOLVj//eC6j3MecLNAmerm+6WOKRxnYsURtM91AEEXVK1waktSTAVeHk8X yiIAW/vlB2OUJj09pnYNicASCyvpxFm/JeMBhK60MZLVqeV64w9sXFzvZ/DnY3AYsVk0 cBNg== X-Forwarded-Encrypted: i=1; AJvYcCXAp60Pf69yuKQEuo0zNo6bdvld+XVJ4o+Au+5kzbQrXJkurz0nzYpQjnmhU7CJi3s3DvlJ1WeAsQ==@kvack.org X-Gm-Message-State: AOJu0Yy6R1L4mG2f8NMRkw7RJzYCEz28+fId99CCIK0XOoIja/eVFRej 7NGJbxgncQ7BDZhFnsplA1sLyJq1NTCKBXddGheenQr/8BBwKeDhwuQg+g56H7Ar8a6Py+2Um/5 kxRXpxHX6wuErknbo4WWGZw0U0SAV9d+aHk1OQ8mTXiSHjTKh X-Gm-Gg: ASbGncvaJ6kK2ea0KPkcz1HFNgIMrF/nQAnTl1XV5ZZmXZIFkcBOAM07zJJu63EQIcP TKw5dq6eb+1i+yqOJ6VrMhefEo+s/01EjdppmRFlkluF1eLA/qm4PdQWV8Ol1dlmaBrzp71xKEI 7Z+XYn4cUroRShLCHGgzrq7rgraSdeRcX6UdxzXcaECbH2RUZcMzMSWjVsIiMjUDUEmb52LMwP6 dH61l1F/Lv6eMb1heyp71i5/J9a5TJvq5Lkpr1N4Rk7bRV2Gum8kkq7K1z7jHUmE1j17+lhyvYo 6Pv3gwvcrhp55ilz02qDx+2IvhthO/Hu49yVdFngeGc8wXLa7euL0uY= X-Received: by 2002:a05:6214:1302:b0:6d8:861f:adca with SMTP id 6a1803df08f44-6e1b2235c9fmr497774526d6.42.1737732153330; Fri, 24 Jan 2025 07:22:33 -0800 (PST) X-Google-Smtp-Source: AGHT+IE5TeadQAXYF5iUiWYdZcwN/B3B0GhQEA3OgvrN+YGY06rhpOtkdAXjp93P8gBhIIoKYtqxZQ== X-Received: by 2002:a05:6214:1302:b0:6d8:861f:adca with SMTP id 6a1803df08f44-6e1b2235c9fmr497773786d6.42.1737732152904; Fri, 24 Jan 2025 07:22:32 -0800 (PST) Received: from vschneid-thinkpadt14sgen2i.remote.csb (213-44-141-166.abo.bbox.fr. [213.44.141.166]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6e2058c2a51sm9344776d6.109.2025.01.24.07.22.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Jan 2025 07:22:32 -0800 (PST) From: Valentin Schneider To: Uladzislau Rezki Cc: Uladzislau Rezki , Jann Horn , linux-kernel@vger.kernel.org, x86@kernel.org, virtualization@lists.linux.dev, linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev, linux-riscv@lists.infradead.org, linux-perf-users@vger.kernel.org, xen-devel@lists.xenproject.org, kvm@vger.kernel.org, linux-arch@vger.kernel.org, rcu@vger.kernel.org, linux-hardening@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, bpf@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com, Juergen Gross , Ajay Kaher , Alexey Makhalov , Russell King , Catalin Marinas , Will Deacon , Huacai Chen , WANG Xuerui , Paul Walmsley , Palmer Dabbelt , Albert Ou , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Peter Zijlstra , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , "Liang, Kan" , Boris Ostrovsky , Josh Poimboeuf , Pawan Gupta , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Arnd Bergmann , Frederic Weisbecker , "Paul E. McKenney" , Jason Baron , Steven Rostedt , Ard Biesheuvel , Neeraj Upadhyay , Joel Fernandes , Josh Triplett , Boqun Feng , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juri Lelli , Clark Williams , Yair Podemsky , Tomas Glozar , Vincent Guittot , Dietmar Eggemann , Ben Segall , Mel Gorman , Kees Cook , Andrew Morton , Christoph Hellwig , Shuah Khan , Sami Tolvanen , Miguel Ojeda , Alice Ryhl , "Mike Rapoport (Microsoft)" , Samuel Holland , Rong Xu , Nicolas Saenz Julienne , Geert Uytterhoeven , Yosry Ahmed , "Kirill A. Shutemov" , "Masami Hiramatsu (Google)" , Jinghao Jia , Luis Chamberlain , Randy Dunlap , Tiezhu Yang Subject: Re: [PATCH v4 29/30] x86/mm, mm/vmalloc: Defer flush_tlb_kernel_range() targeting NOHZ_FULL CPUs In-Reply-To: References: <20250114175143.81438-1-vschneid@redhat.com> <20250114175143.81438-30-vschneid@redhat.com> Date: Fri, 24 Jan 2025 16:22:19 +0100 Message-ID: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: udJrCP9H3yRdCIQvD2uDg7B2c6Z7F4iettHrLUFQSQE_1737736313 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Rspam-User: X-Rspamd-Queue-Id: B9956120003 X-Rspamd-Server: rspam10 X-Stat-Signature: b6gaoch65brk8fw45zew4dpz9opsiyb8 X-HE-Tag: 1737736315-302472 X-HE-Meta: U2FsdGVkX1/M+N19swL0Fj7lTNTbg6oDjZT2rjku9EXY2LbGOkkMFwdb6vrZPAXKEjQyInobeD+irzTarbW0xSRef1+O9FaTEu6HK6mDTpWcYoI8ATGMBXYl0tTNQZkOwEPz37+1YL7wARq9xiy7TmAag/KAl/adWUQOmKgqi/I6zcfjE1+cLptlFAf/YwSJJQnGD1z+cZtWuQhH8hwRzhGtcrnWiuspNPeoRqO8pQ9Uf6N2DJAspS1xzBsgA3T58g2l9RYzczrU5nyDi5Rt1I9ACWaCCnV5lpUWw+SVg5o8BJITEvQ8X5UbEt/bCeciCwSerJST1k0zxx92NTZjFq0TSQPJU4QzCHNLpWd3/BJotUX1U5s5kbzQ4pyTIU0B6lB2JjPecqeMJoQyR5l6idIWYiPoZi4ltzmPHXMXHkGNR0jzXEeGGttROJxuAlMhOvQFx+6VIroXVVqrcnXOMx6rJkAZfbwa1Kgc3h2bR4OWJAv3SqYzLZsD/izT5nPj+h1SRlOXuhGg2X4/jYqFo0NjOkLpUfDllfRH8HfQeMiBpXDZKCiQOGCq/zpaBaVt3NrpusJEQ7vYwJzUrZeTsYoj8aUAeftSEWJWcGkolHCGG2UlkLxHe2Ks5beMRyeuJLcwSA/1AZbQQpGtm5W+UoD3zw06tt32pmW4dsXdYhd3VuDMFFYGUynqE97JFs5PleNq1eUMe2RLCfPRB2gaBbqByAHhYDmV8JVbDFdvtpZFWZliDsLZIjmwfwYLzagMNBIoqL0UT6esdT9Fud5Sf2CbBb8rkKfTTMkX4J7RMLjFftMzYoXdgdxg6SM7JKbJjYr34rKxfQ8k2wVtD9dXiNMWp8lHXXix1niynpMnPWFRqMwnelMN2aC8F6KFZ6vK0WFz6bVNAg3dzsmD8duSB9XPDwCfNmZabB/3B7Vi+e9ulpePEg3ECzQQJJ8OS8RX+zoE4Htsr9Sd0vn74qm FelsjidX w0gz36dp1iMZHsHvYIaXdSUHhoDwYmQ0bWxfOwtTQWV0r8NwoQgY/wmxboIfEm5J+0JN5zO68BXNul5ulkJmYdS60BlG8RI5Vm9LinhkPavGGFqebdzQnqGd9yCOWfoql863PqJoXEzzQ2eQDuafQ5eL2mgYWBxKJaerj6sRNXpxlIY2yp4YWjmLbQ/yDJNr8SiAIPbkNxILStz51uKPVtoFBV5QNKU+DWvIWQX4zMuw/F5e6owXgpbwP4Mq87GaW7xPWDv4vKsS9swLz6g7CHc/lS/iHoJcuwcPYkz4geN7847rACQCFqn2/yK6N1D3avE3mDn5WRWyTgGBa/uJ/WkmVj8br7Nzo7RscV7gjLmoIF40K0jzCyEIsOHjO5L9+Sm2Y 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: List-Subscribe: List-Unsubscribe: On 21/01/25 18:00, Uladzislau Rezki wrote: >> > >> > As noted before, we defer flushing for vmalloc. We have a lazy-threshold >> > which can be exposed(if you need it) over sysfs for tuning. So, we can add it. >> > >> >> In a CPU isolation / NOHZ_FULL context, isolated CPUs will be running a >> single userspace application that will never enter the kernel, unless >> forced to by some interference (e.g. IPI sent from a housekeeping CPU). >> >> Increasing the lazy threshold would unfortunately only delay the >> interference - housekeeping CPUs are free to run whatever, and so they will >> eventually cause the lazy threshold to be hit and IPI all the CPUs, >> including the isolated/NOHZ_FULL ones. >> > Do you have any testing results for your workload? I mean how much > potentially we can allocate. Again, maybe it is just enough to back > and once per-hour offload it. > Potentially as much as you want... In our Openshift environments, you can get any sort of container executing on the housekeeping CPUs and they're free to do pretty much whatever they want. Per CPU isolation they're not allowed/meant to disturb isolated CPUs, however. > Apart of that how critical IPIing CPUs affect your workloads? > If I'm being pedantic, a single IPI to an isolated CPU breaks the isolation. If we can't quiesce IPIs to isolated CPUs, then we can't guarantee that whatever is running on the isolated CPUs is actually isolated / shielded from third party interference.