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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7ADEEC6369E for ; Thu, 19 Nov 2020 01:40:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C9AA8246CA for ; Thu, 19 Nov 2020 01:40:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C9AA8246CA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 40DDF6B005D; Wed, 18 Nov 2020 20:40:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3BE3D6B006C; Wed, 18 Nov 2020 20:40:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 19AEA6B006E; Wed, 18 Nov 2020 20:40:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0045.hostedemail.com [216.40.44.45]) by kanga.kvack.org (Postfix) with ESMTP id D838B6B005D for ; Wed, 18 Nov 2020 20:40:35 -0500 (EST) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 87D481EE6 for ; Thu, 19 Nov 2020 01:40:35 +0000 (UTC) X-FDA: 77499463230.01.chair76_20044402733f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin01.hostedemail.com (Postfix) with ESMTP id 6C23C1004ED8A for ; Thu, 19 Nov 2020 01:40:35 +0000 (UTC) X-HE-Tag: chair76_20044402733f X-Filterd-Recvd-Size: 6834 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Thu, 19 Nov 2020 01:40:33 +0000 (UTC) IronPort-SDR: XHApzAVeHh/x20NhCQgTI5U5T95g7JdMJfDTzdhbUC392qKdA8h9ksLhYV+8URF7CeGgBa9Koq sHWu6PMzXoJg== X-IronPort-AV: E=McAfee;i="6000,8403,9809"; a="235361088" X-IronPort-AV: E=Sophos;i="5.77,489,1596524400"; d="scan'208";a="235361088" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Nov 2020 17:40:32 -0800 IronPort-SDR: /m/vbItLyd2oyz9x2V6TwUFWFBoTHt+spnU9wCof8SwbnDxU4EE1dY5oVBst2vn6nJm1SqRY8l lyU6NVaes3SA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,489,1596524400"; d="scan'208";a="359744167" Received: from yhuang-dev.sh.intel.com (HELO yhuang-dev) ([10.239.159.50]) by fmsmga004.fm.intel.com with ESMTP; 18 Nov 2020 17:40:29 -0800 From: "Huang\, Ying" To: Uladzislau Rezki Cc: huang ying , Andrew Morton , linux-mm@kvack.org, LKML , Hillf Danton , Michal Hocko , Matthew Wilcox , Oleksiy Avramchenko , Steven Rostedt , Christoph Hellwig Subject: Re: [PATCH 2/2] mm/vmalloc: rework the drain logic References: <20201116220033.1837-1-urezki@gmail.com> <20201116220033.1837-2-urezki@gmail.com> <20201117130434.GA10769@pc636> <20201118161623.GA21171@pc636> Date: Thu, 19 Nov 2020 09:40:29 +0800 In-Reply-To: <20201118161623.GA21171@pc636> (Uladzislau Rezki's message of "Wed, 18 Nov 2020 17:16:23 +0100") Message-ID: <87mtzeunsi.fsf@yhuang-dev.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii 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: Uladzislau Rezki writes: > On Wed, Nov 18, 2020 at 10:44:13AM +0800, huang ying wrote: >> On Tue, Nov 17, 2020 at 9:04 PM Uladzislau Rezki wrote: >> > >> > On Tue, Nov 17, 2020 at 10:37:34AM +0800, huang ying wrote: >> > > On Tue, Nov 17, 2020 at 6:00 AM Uladzislau Rezki (Sony) >> > > wrote: >> > > > >> > > > A current "lazy drain" model suffers from at least two issues. >> > > > >> > > > First one is related to the unsorted list of vmap areas, thus >> > > > in order to identify the [min:max] range of areas to be drained, >> > > > it requires a full list scan. What is a time consuming if the >> > > > list is too long. >> > > > >> > > > Second one and as a next step is about merging all fragments >> > > > with a free space. What is also a time consuming because it >> > > > has to iterate over entire list which holds outstanding lazy >> > > > areas. >> > > > >> > > > See below the "preemptirqsoff" tracer that illustrates a high >> > > > latency. It is ~24 676us. Our workloads like audio and video >> > > > are effected by such long latency: >> > > >> > > This seems like a real problem. But I found there's long latency >> > > avoidance mechanism in the loop in __purge_vmap_area_lazy() as >> > > follows, >> > > >> > > if (atomic_long_read(&vmap_lazy_nr) < resched_threshold) >> > > cond_resched_lock(&free_vmap_area_lock); >> > > >> > I have added that "resched threshold" because of on my tests i could >> > simply hit out of memory, due to the fact that a drain work is not up >> > to speed to process such long outstanding list of vmap areas. >> >> OK. Now I think I understand the problem. For free area purging, >> there are multiple "producers" but one "consumer", and it lacks enough >> mechanism to slow down the "producers" if "consumer" can not catch up. >> And your patch tries to resolve the problem via accelerating the >> "consumer". >> > Seems, correct. But just in case one more time: > > the cond_resched_lock was added once upon a time to get rid of long > preemption off time. Due to dropping the lock, "producers" can start > generate further vmap area, so "consumer" can not catch up. Seems Yes. And in theory there are vfree() storm, that is, thousands vfree() can be called in short time. But I don't think that's practical use case. > Later on, a resched threshold was added. It is just a simple protection > threshold, passing which, a freeing is prioritized back over allocation, > so we guarantee that we do not hit out of memory. Yes. That can accelerate freeing if necessary. >> >> That isn't perfect, but I think we may have quite some opportunities >> to merge the free areas, so it should just work. >> > Yes, merging opportunity should do the work. But of course there are > exceptions. > >> And I found the long latency avoidance logic in >> __purge_vmap_area_lazy() appears problematic, >> >> if (atomic_long_read(&vmap_lazy_nr) < resched_threshold) >> cond_resched_lock(&free_vmap_area_lock); >> >> Shouldn't it be something as follows? >> >> if (i >= BATCH && atomic_long_read(&vmap_lazy_nr) < >> resched_threshold) { >> cond_resched_lock(&free_vmap_area_lock); >> i = 0; >> } else >> i++; >> >> This will accelerate the purging via batching and slow down vmalloc() >> via holding free_vmap_area_lock. If it makes sense, can we try this? >> > Probably we can switch to just using "batch" methodology: > > > if (!(i++ % batch_threshold)) > cond_resched_lock(&free_vmap_area_lock); > That's the typical long latency avoidance method. > The question is, which value we should use as a batch_threshold: 100, 1000, etc. I think we can do some measurement to determine it? > Apart of it and in regard to CONFIG_KASAN_VMALLOC, it seems that we are not > allowed to drop the free_vmap_area_lock at all. Because any simultaneous > allocations are not allowed within a drain region, so it should occur in > disjoint regions. But i need to double check it. > >> >> And, can we reduce lazy_max_pages() to control the length of the >> purging list? It could be > 8K if the vmalloc/vfree size is small. >> > We can adjust it for sure. But it will influence on number of global > TLB flushes that must be performed. Em... For example, if we set it to 100, then the number of the TLB flushes can be reduced to 1% of the un-optimized implementation already. Do you think so? Best Regards, Huang, Ying