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 98F1BC43334 for ; Tue, 21 Jun 2022 12:15:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B1A136B0072; Tue, 21 Jun 2022 08:15:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AC93A6B0073; Tue, 21 Jun 2022 08:15:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9B7F26B0074; Tue, 21 Jun 2022 08:15:55 -0400 (EDT) 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 8CAE06B0072 for ; Tue, 21 Jun 2022 08:15:55 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 5190A10F8 for ; Tue, 21 Jun 2022 12:15:55 +0000 (UTC) X-FDA: 79602139470.02.46F29AE Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) by imf05.hostedemail.com (Postfix) with ESMTP id D424E100018 for ; Tue, 21 Jun 2022 12:15:54 +0000 (UTC) Received: by mail-pg1-f170.google.com with SMTP id q140so12947737pgq.6 for ; Tue, 21 Jun 2022 05:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:mime-version:content-disposition; bh=IhRlwR2iBJ2AGg39HG7ecPjXBsP+992iS71lB4PQRYs=; b=QbnardF/zZ8JGOI2mPyYYD0B3LKUxxvbEkg6ISCDHbgcswZSqNNHtc/6jkx3YKJZth Tzhdvz767wKB7ukMZ1bCfTKBME2e/L5k7yuzcwsbg3btLHcCL9mgaw6Jh8780R2S44Hs U1H9dqOFrq1c4m8WcmIXOSxO+kzAcvXhrN4+ITQOEdNeEBSh0npoC+ca98iLZEtmSVSR dUbyvJkE1ncGzISa96VJZDxyCwM/lf5trImqsO8456m2lL6W8y9c1BysZQwOOUs9EUNt qc3wKBIzidSmmbW9fB2W/55fyEy+7axKhlv8jFszrgprTM07l7iRDtyRiTX+IkOnePND 8DCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition; bh=IhRlwR2iBJ2AGg39HG7ecPjXBsP+992iS71lB4PQRYs=; b=n+p9IEYyADSmmaVgFCFxKkLeUaQfnQgBN5aRMfqitVI7JyID8ZdIQGgonIunfUUFD8 zsuIwxBW5GJ3XZ10hVM3BXXx2uT8EA/kLkePaFVM4DLo06W70cZ2Rx7WXmpSjTVqaDQR nAsmju3etk4fkDx8tKj0dwWMhmW1NrAv9SP2MSQJzeuFlEXrKY2Y2uoEOPorfM3LEzCw etCFXsiceBkMTL/Et+wbiUmvpgE60tjAE3m0U4lVlxEEYbBRIy47KCs4vctu3MmrZ4ZE Krm0xpd+xHDjrzBizSr6+SSbErHENPU1M1agxMPAKkYUg3gHChY2pwtrv+WGu+efI0FR SxTw== X-Gm-Message-State: AJIora8QYqlGZPWxHv11mActQ8ZiTek9I3OE1WHS+If2OZgsUmb1SEyE zSXprhgcdLSV+sttSr5bI7CLM3jfPuY= X-Google-Smtp-Source: AGRyM1seNI2FKt3/V9+nzbRFmEUFaZDK7Ai/RlbJTCXo3u37c+dAVm25Ny0bySoYGQy04Cb260V3OQ== X-Received: by 2002:a63:af53:0:b0:40c:b4de:9215 with SMTP id s19-20020a63af53000000b0040cb4de9215mr9543801pgo.97.1655813753325; Tue, 21 Jun 2022 05:15:53 -0700 (PDT) Received: from ubuntu20 (60-249-39-197.hinet-ip.hinet.net. [60.249.39.197]) by smtp.gmail.com with ESMTPSA id u11-20020a170902e80b00b0016a0858b25dsm8196445plg.152.2022.06.21.05.15.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Jun 2022 05:15:52 -0700 (PDT) Date: Tue, 21 Jun 2022 20:15:47 +0800 From: Zhipeng Shi To: linux-mm@kvack.org, linux-rt-users@vger.kernel.org Cc: tglx@linutronix.de, shengjian.xu@horizon.ai, schspa@gmail.com Subject: [Question] vmalloc latency in RT-Linux Message-ID: <20220621121547.GB37196@ubuntu20> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655813754; a=rsa-sha256; cv=none; b=3JEDi+jcr+xDAGf60ezN5t7a3q1ZalzVaqnnqeP7RlSugUOIYTs05hrwH7WvEGLiu5QBfe tdjGZl29zaLDPi0wvZYX3cSkoxwme9Uz29/R8v2fRsiQw1TLN8mBKZDx2/5H19ZGQOzXC5 dRk9JfELXXJTYFSZI6d9WwR3ZiOI+Tw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655813754; 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: references:dkim-signature; bh=IhRlwR2iBJ2AGg39HG7ecPjXBsP+992iS71lB4PQRYs=; b=lwO40Yeqbin1T7bwaqQWaVtFXiFrI3jHq9BRfM7sj1Yr259Fz5bQRP/MToZzBVW+B2Srga Bx9+qUNy8zqtRb/KJwrhX0yNvekOHQPwHeqLizVlKEKwbcvqj98RO4GOvRSe0TR7b8KXMZ VyfsJyMe3tc2mwU9F9HbwIBRsYlR5WU= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="QbnardF/"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf05.hostedemail.com: domain of zhipeng.shi0@gmail.com designates 209.85.215.170 as permitted sender) smtp.mailfrom=zhipeng.shi0@gmail.com Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="QbnardF/"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf05.hostedemail.com: domain of zhipeng.shi0@gmail.com designates 209.85.215.170 as permitted sender) smtp.mailfrom=zhipeng.shi0@gmail.com X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: D424E100018 X-Stat-Signature: ks8ifmgwyhxwaey3s6jnrrfe1rw7u4en X-HE-Tag: 1655813754-13463 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: I noticed in rt-linux, vmalloc has a large latency. This is because the free_vmap_area_lock is held for a long time in the function __purge_vmap_area_lazy. In non-RT-Linux, because the function spin_is_contended is well implemented, so there will be no such problem. But in RT-Linux, spin_is_contended simply returns 0. I don't understand why this function was implemented like this before, but in order to solve this problem, I thought of two ways. The first is to modify the spin_is_contended definition in spinlock_rt.h as shown below, but I'm not sure if the change has side-effects: -#define spin_is_contended(lock) (((void)(lock), 0)) +static inline int spin_is_contended(spinlock_t *lock) +{ + unsigned long *p = (unsigned long *) &lock->lock.owner; + + return (READ_ONCE(*p) & RT_MUTEX_HAS_WAITERS); +} The second is by reducing the number of lazy_max_pages, but it will lead to lower performance of vmalloc. Guys, Do you have any good ideas? Best regards, Zhipeng