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=-4.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 A5509C56201 for ; Thu, 19 Nov 2020 17:36:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C172F22260 for ; Thu, 19 Nov 2020 17:36:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="X8ry30GX" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C172F22260 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A56A36B005C; Thu, 19 Nov 2020 12:36:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A08AA6B005D; Thu, 19 Nov 2020 12:36:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F9276B0068; Thu, 19 Nov 2020 12:36:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0020.hostedemail.com [216.40.44.20]) by kanga.kvack.org (Postfix) with ESMTP id 5B8266B005C for ; Thu, 19 Nov 2020 12:36:10 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 50298349B for ; Thu, 19 Nov 2020 17:36:09 +0000 (UTC) X-FDA: 77501871258.13.sound85_5b0338a27344 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin13.hostedemail.com (Postfix) with ESMTP id 26D4518140B67 for ; Thu, 19 Nov 2020 17:36:09 +0000 (UTC) X-HE-Tag: sound85_5b0338a27344 X-Filterd-Recvd-Size: 9263 Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com [209.85.167.66]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Thu, 19 Nov 2020 17:36:08 +0000 (UTC) Received: by mail-lf1-f66.google.com with SMTP id j205so9413507lfj.6 for ; Thu, 19 Nov 2020 09:36:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=AMEfcRZyDbM50viNn70TO3tAhFtDRzkX2NtxBHmPeO4=; b=X8ry30GXNTORZXNY+OjXb0UPQ8k82UKFXpWbqvK6BW+4LqLaJVUgflFnnJNrz9JSDi rw1j9ax4aZ2PpaOK/5Xt/CP5ONOJ842KQQNmLcrj5acb3VbSnBW1pirriQUL4v8gEhg4 gr6VI7NiD98OvXD/dWOoO5PfnGG1rmi77oPzGSZPRreu7Fg2juO//sqabOdRZh1tp2RC rcxOynBTfieqRPJnV7+KhjG+eckKwq8xPZgiAMTgl2dZDUdkmya3BPaNZqXWXxAxY7iz kc2GgFYSvvNJV9tQ4d2T5helECw9my7HrZXrSwcWGxgtpj0nSKpuzRjVdcwzWjVDyXdW VLIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=AMEfcRZyDbM50viNn70TO3tAhFtDRzkX2NtxBHmPeO4=; b=D4x/+LUr1Q3dh8gW4CpnjbjzKtenKarr37N7Dn+M+WJ92gHBKVknY5awR/MaU7+bhi Q+OiLKZsQ1jjNNo9SBvx1un7YSWn1lep+3pb8m1CCmNqEFmfh4/V4oE9SfetLB8XzlYI x7/0d+JQuLWN/rg4xvA9MqEd/DaODU5b3lwb6LJ4U2AZ9sdxl5ksydQHhcrfEjrxieCE pdcO+AQ4gSN34lINu1g2tB3zlkOA2gt5Af9Ixmd2SxpRo1bFwSzY+G9QNN3k+sisBRv2 qft4Er7t2rV+aY89FH0JgydvF7vvNgRUNs/+VlB1kFuSA4oNonuv+rqC22N72Ql+R6sD LVHA== X-Gm-Message-State: AOAM530UOIeJYmHt/x4audbXPzlncV+0DjDHD3d+t09Vew0HBxMMfyH+ 5B/ZeNztWlzlmhFO1lr5o6A= X-Google-Smtp-Source: ABdhPJzRC11aJaTcuVHdEgeBTCumt/WsKoq0korwAsDLZ9gmgzgMR5LnI2hq4i0mrQ/FAiAiZCiGQQ== X-Received: by 2002:a19:c1c5:: with SMTP id r188mr6821458lff.354.1605807367020; Thu, 19 Nov 2020 09:36:07 -0800 (PST) Received: from pc636 (h5ef52e3d.seluork.dyn.perspektivbredband.net. [94.245.46.61]) by smtp.gmail.com with ESMTPSA id q13sm29732lfk.147.2020.11.19.09.36.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Nov 2020 09:36:06 -0800 (PST) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Thu, 19 Nov 2020 18:36:04 +0100 To: "Huang, Ying" Cc: Uladzislau Rezki , 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 Message-ID: <20201119173604.GA991@pc636> References: <20201116220033.1837-1-urezki@gmail.com> <20201116220033.1837-2-urezki@gmail.com> <20201117130434.GA10769@pc636> <20201118161623.GA21171@pc636> <87mtzeunsi.fsf@yhuang-dev.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87mtzeunsi.fsf@yhuang-dev.intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) 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 Thu, Nov 19, 2020 at 09:40:29AM +0800, Huang, Ying wrote: > 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? > Hmm.. looking at it one more time i do not see what batching solves. Anyway we need to have some threshold(what we do have), that regulates a priority between vmalloc()/vfree(). What we can do more with it are: - purging should be just performed asynchronously in workqueue context. Giving the fact, that now we also do a merge of outstanding areas, the data structure(rb-tree) will not be so fragmented. - lazy_max_pages() can slightly be decreased. If there are existing workloads which suffer from such long value. It would be good to get real complains and evidence. > > 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? > If we set lazy_max_pages() to vague value such as 100, the performance will be just destroyed. Thanks! -- Vlad Rezki