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 2D035C5519F for ; Wed, 18 Nov 2020 16:16:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 71C30247E0 for ; Wed, 18 Nov 2020 16:16:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="dOsYA9VE" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 71C30247E0 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 848706B0078; Wed, 18 Nov 2020 11:16:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 81D5D6B007E; Wed, 18 Nov 2020 11:16:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7355A6B0081; Wed, 18 Nov 2020 11:16:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0226.hostedemail.com [216.40.44.226]) by kanga.kvack.org (Postfix) with ESMTP id 089226B0078 for ; Wed, 18 Nov 2020 11:16:28 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 89CD5180AD822 for ; Wed, 18 Nov 2020 16:16:28 +0000 (UTC) X-FDA: 77498041656.26.sense18_5f00cda2733b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id 607E01804B640 for ; Wed, 18 Nov 2020 16:16:28 +0000 (UTC) X-HE-Tag: sense18_5f00cda2733b X-Filterd-Recvd-Size: 7606 Received: from mail-lf1-f65.google.com (mail-lf1-f65.google.com [209.85.167.65]) by imf25.hostedemail.com (Postfix) with ESMTP for ; Wed, 18 Nov 2020 16:16:27 +0000 (UTC) Received: by mail-lf1-f65.google.com with SMTP id l11so3790729lfg.0 for ; Wed, 18 Nov 2020 08:16:27 -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=dxGJzTPzfGqlw2eREZnl/81tfb5sqRiBYpaj7YA+TgI=; b=dOsYA9VE0g4ahGGUcPyY47F9nTBcOmKwvKoS/oErU5qrQCT/81NNjtnzn+BfOl78ae R6/4Mm8K+DuU8UsnZSm3CSdA+7dlazyj5PhmJoOuekCnfNgwRVF8Qxjho76GAA4xTLJB 9lTQwBsNJxtUV63SGXYiHU4g0qybK7BwqI5Em+9Zjq5L55eGy6jgOmutGmeqfrHKuxx+ flP5TMzGIKenWwZq736eCIwtice8OGlQmYOz9myoX9tqjK0TbJAuI/XhnrJ2mDvNOKLQ +9D0X8p2KHFqhb4hi4YXpeGphW9HvpLNARq5pTqsXVq6hQH30dDjs08Y5qSi70vI0uA/ 4YeA== 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=dxGJzTPzfGqlw2eREZnl/81tfb5sqRiBYpaj7YA+TgI=; b=Mpmv3o4aAD2HhqKEVrKHj1ONRMVi4nnRxIsTS/nJPjG0ntfn8/bndrY9JeNGnIBLKf BMHF3cTS1rvNP7yyHhVNbIksHDpfWbxtnPFE9A5VM3OxR0Q42r9xPTUfmq9BFbkXny3z SzjVikBwX8cANCpmoXSCC6KwgI9isURTT615JBGyKI8WI1GVDfI423i3wjzJJ1UnJNbX SEXgU1rUeFHMnbn+83bJGRlu754BM4zW6sEhVch8nsuZtMC7uSJFV9mq545AmQKYVYyW spPmSG59Ab3X79PBrs+VAw4so6oJJlcEbeoelQITnzjdLUVOx4rRv3pKH9cEiWSd3XOE QPMg== X-Gm-Message-State: AOAM531cihRDtcONUGeNaiKnvxx8jdoimG7NcesrsNrwVHQAWbtEC5CY cSRFxvjbUyE8Q/xh+WBRWpw= X-Google-Smtp-Source: ABdhPJwh8ZZQcru32BvECvUnG9uLIIUaHfDXf2K7dPs+RpVGX3F7Hyy6b5KfhXtyo12NbB4YvfDD8Q== X-Received: by 2002:a19:d02:: with SMTP id 2mr3858602lfn.294.1605716186014; Wed, 18 Nov 2020 08:16:26 -0800 (PST) Received: from pc636 (h5ef52e3d.seluork.dyn.perspektivbredband.net. [94.245.46.61]) by smtp.gmail.com with ESMTPSA id a26sm1492457ljn.137.2020.11.18.08.16.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Nov 2020 08:16:25 -0800 (PST) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Wed, 18 Nov 2020 17:16:23 +0100 To: huang ying Cc: Uladzislau Rezki , Andrew Morton , linux-mm@kvack.org, LKML , Hillf Danton , Michal Hocko , Matthew Wilcox , Oleksiy Avramchenko , Steven Rostedt , Huang Ying , Christoph Hellwig Subject: Re: [PATCH 2/2] mm/vmalloc: rework the drain logic Message-ID: <20201118161623.GA21171@pc636> References: <20201116220033.1837-1-urezki@gmail.com> <20201116220033.1837-2-urezki@gmail.com> <20201117130434.GA10769@pc636> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 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 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. > > 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); The question is, which value we should use as a batch_threshold: 100, 1000, etc. 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. Thanks. -- Vlad Rezki