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 D55F4C43334 for ; Fri, 24 Jun 2022 05:56:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 347E18E01E6; Fri, 24 Jun 2022 01:56:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D1D78E01E3; Fri, 24 Jun 2022 01:56:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1710C8E01E6; Fri, 24 Jun 2022 01:56:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 029AA8E01E3 for ; Fri, 24 Jun 2022 01:56:41 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id C85C460B42 for ; Fri, 24 Jun 2022 05:56:41 +0000 (UTC) X-FDA: 79612070202.31.A7CA11D Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com [209.85.215.180]) by imf15.hostedemail.com (Postfix) with ESMTP id 522E0A0022 for ; Fri, 24 Jun 2022 05:56:41 +0000 (UTC) Received: by mail-pg1-f180.google.com with SMTP id h192so1477120pgc.4 for ; Thu, 23 Jun 2022 22:56:41 -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:references:mime-version :content-disposition:in-reply-to; bh=kR9Bh5KsE8AoUOfzfRXUJn9Sy+bHJBXRlap3Lj0cwbc=; b=H3tUhDuGJaXKFwSfEOEFiNFx8jPd1uzztiVb3iRWrFe1m1wWg3DeIf43Fe2l2kLgG7 M+iadcveJ9scg5aUgdQ3HP0v9QbknpwSCWYvRKesl72bSmMJUbHX7t0x9CVDAPWVfwmS 7HFqu2x47HeVg7zKJETlp8UGrNQHpkejFPmxvaeLTtbO55ZVrppmwtgdVExm010vaB6h bf8/k3L2dBF7OmwULAPBwPhsAGiWEBtlD/aiIKUaKCs1j5ZzaNDU5OV9dcTdJRTSRIv/ H7ur5t0a8JIgpmLRy1VfLSavZu3BepK8ZjNLhqRIrL6SAqh6jNfRHBq4VLWYfHTX47GB weFA== 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:references :mime-version:content-disposition:in-reply-to; bh=kR9Bh5KsE8AoUOfzfRXUJn9Sy+bHJBXRlap3Lj0cwbc=; b=0Ze1vZu6+34lXmA0mOyASSHgrThro35P+h3J4E19A0HZi8/2YdyhHVXcWAhg2gKOgJ DeLYIdRgudlMS8BMqvEQ6jsn9DgiK2IJ3CBIJchDmqjI0/buYNfcnjdOYUeeLjflRFnT iCMf6iOjFk+fnXYyeEQfDVslTZMAvmy5QQqpPQz8gDeO2/gfHwJ1z6wV6iEc4DMjRnZA Jh1V8pTXoq0kChPdLVp1Ezkx3D8vq0soVxsvwXSZmMVySM3i1cBfv/7k0jDf2CqXEV5U Lmsz0DgBJtnunE0iac9BGwrxOLIEUtufePcI843+UB6HAfvZvO7eHXWVlBC2j6hYhAsv A/vQ== X-Gm-Message-State: AJIora9HP8lzZQfbZ+2LE49ijWfkpk9dmFO/13yjgKSlZywSoEDE7Plc FkE/ZcQSskiKDC2ivTAbwg0= X-Google-Smtp-Source: AGRyM1t8pSvn8n7TF/pNsuudTZq4ZY2Alcbl9MZXQ+AHDxattVEzXvsn9nf3TJRHq04M+sioWSNA9Q== X-Received: by 2002:a63:2ccb:0:b0:3fe:1929:b30b with SMTP id s194-20020a632ccb000000b003fe1929b30bmr10534948pgs.64.1656050200065; Thu, 23 Jun 2022 22:56:40 -0700 (PDT) Received: from ubuntu20 (60-249-39-197.hinet-ip.hinet.net. [60.249.39.197]) by smtp.gmail.com with ESMTPSA id t5-20020a17090abc4500b001ea629a431bsm796945pjv.8.2022.06.23.22.56.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jun 2022 22:56:39 -0700 (PDT) Date: Fri, 24 Jun 2022 13:56:33 +0800 From: Zhipeng Shi To: Baoquan He , Waiman Long Cc: linux-mm@kvack.org, linux-rt-users@vger.kernel.org, tglx@linutronix.de, shengjian.xu@horizon.ai, schspa@gmail.com, Sebastian Andrzej Siewior , peterz@infradead.org Subject: Re: [Question] vmalloc latency in RT-Linux Message-ID: <20220624055633.GA836199@ubuntu20> References: <20220621121547.GB37196@ubuntu20> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656050201; 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=kR9Bh5KsE8AoUOfzfRXUJn9Sy+bHJBXRlap3Lj0cwbc=; b=yojFggudWBEPvnllhtp+T7+Rhuv3jFTqsIaPo21nN2pOb9nkCl4YHjUpIWbx02Fi2QUMFu 0K7G9g6rSFfreS/T4NxpYK72fGpFAZTqquNPRB8ZUPmG8HHY4oUltL0BK2G3ioVhMIxHOB j+eq2YCbr6JbIPFDG/avRCea4nrpfx4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656050201; a=rsa-sha256; cv=none; b=S29WGLbJSSEQ68ByqBiGag/Ziwos+/pAApkBreBgkm0JjYyk83J10e086QvZHFERYu7H82 G40bg9e22CeIZhvLEKjyVR6y0SpeM1d60b7UXR6TLhBldX0wKqFhH9X82ZoM9Mo77UWSDL dq0886dB31+Oc9p3rSE4UijhDbL9eZU= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=H3tUhDuG; spf=pass (imf15.hostedemail.com: domain of zhipeng.shi0@gmail.com designates 209.85.215.180 as permitted sender) smtp.mailfrom=zhipeng.shi0@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=H3tUhDuG; spf=pass (imf15.hostedemail.com: domain of zhipeng.shi0@gmail.com designates 209.85.215.180 as permitted sender) smtp.mailfrom=zhipeng.shi0@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 522E0A0022 X-Stat-Signature: 5jgoidr3edgssry77ery763o9x6uk8n8 X-HE-Tag: 1656050201-236980 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: On Fri, Jun 24, 2022 at 10:39:43AM +0800, Baoquan He wrote: > On 06/23/22 at 02:04pm, Waiman Long wrote: > > On 6/23/22 06:51, Baoquan He wrote: > > > On 06/21/22 at 08:15pm, Zhipeng Shi wrote: > > > > 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. > > > __purge_vmap_area_lazy() has cond_resched_lock() to reschedule and drop > > > the lock. From your saying, it's spin_is_contended() which is not > > > working well to make rescheduling happen during __purge_vmap_area_lazy() > > > handling. Then the fixing should be done in lock side. > > > > Sebastian had sent out patch last year to fix spin_is_contended(). > > > > https://lore.kernel.org/lkml/20210906143004.2259141-3-bigeasy@linutronix.de/ > > > > However, there is no follow-up after some discussion and the patch wasn't > > merged. > > That's great. Thanks, Longman. > > Then this is a good chance to reconsider it, maybe with a test from Zhipeng. Before that, since I didn't find the patch that Sebastian sent before, I sent relevant patch for this problem (now it seems that Sebastian's changes are better than mine) and test scripts. please refer to the following links: https://lore.kernel.org/lkml/20220608142457.GA2400218@ubuntu20/ With this patch, max-latency of vmalloc reduce from 10+ msec to 200+ usec, this because spin_lock is released halfway through __purge_vmap_area_lazy. Best regards, Zhipeng