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 80100C56201 for ; Wed, 25 Nov 2020 20:34:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DF3DF206F7 for ; Wed, 25 Nov 2020 20:34:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="eZs/hq/m" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DF3DF206F7 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 253D06B006E; Wed, 25 Nov 2020 15:34:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 232626B0070; Wed, 25 Nov 2020 15:34:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0A23A6B0071; Wed, 25 Nov 2020 15:34:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0102.hostedemail.com [216.40.44.102]) by kanga.kvack.org (Postfix) with ESMTP id DFC206B006E for ; Wed, 25 Nov 2020 15:34:43 -0500 (EST) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id A4E308249980 for ; Wed, 25 Nov 2020 20:34:43 +0000 (UTC) X-FDA: 77524094046.23.wing34_481494627379 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin23.hostedemail.com (Postfix) with ESMTP id 83F4437604 for ; Wed, 25 Nov 2020 20:34:43 +0000 (UTC) X-HE-Tag: wing34_481494627379 X-Filterd-Recvd-Size: 7036 Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Wed, 25 Nov 2020 20:34:42 +0000 (UTC) Received: by mail-lj1-f196.google.com with SMTP id j10so3672116lja.5 for ; Wed, 25 Nov 2020 12:34:42 -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=PTSj273m5dfHVb/AgHhQ3VD6GzY1CwNYoQKrgTLxVPM=; b=eZs/hq/mrBtZxX+zN7fatgTYgzWy27jm2uvhung6pwbgO2U+q/OAqrKWMze5pe7dhp kEgY8rbwL1n8UkILZUdZmxQJGvNU1ZCtRemnm6FVvllW0W33bODVbrvviH7j3//2XSVn yCX/W96vtdRvkrGtS+ch0RmwSDSebovjhL7h07l0tMBZnIFgw/OnL5DTHHht44XPWfPQ 8LvGEcCXn7hkvFSooqP7qdqxQLghWt+J6dwy7x3rwAfMvYsTP62zMMPDI7K8tB7VxYV2 WRQCmzqHJupqRDH90eBZaI9rGNOJwSQYuigFA0IRTcVHZDUngO+ST9d5YljwrjPC58b0 ksbA== 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=PTSj273m5dfHVb/AgHhQ3VD6GzY1CwNYoQKrgTLxVPM=; b=MxiOvt8+L5X6g8p/pOo/njlBZ2Sv+Jr85b+n7FIPI1jVt/BipfKcTTxuOmBCfi2sy4 3nUqdZ475YbrgLjKeKG3qS+9uvg6hUsmyjVmu5siJwE+KNsOSVlPXG21zZHjwJ3wQqhb 9dulM6bRXtES0fW/YRwB+2rmuD90kxE+PvwNlXi/KOJr6cX6yQfsXbH9dzzwbhRAFWi8 IM5sofb9MuZ4Y6OYAYzhvnOzvcunirNOL8utV467JAJVpQENuIpQi7hJflrD6LlYjJ+g GyeotEGRdqUN4NIoHNpvkVfgrRsbzArfbFHlWEAG04PKGiCQ+8FVpOAimDhL/sGsEX0e 9q8A== X-Gm-Message-State: AOAM533+a6/8iXatYj/79en54ieZpWW8rDbhzYWakQBbdiBwlnyF98lG eZh6+gx7ga4hcLZomFJq5/Y= X-Google-Smtp-Source: ABdhPJz+3qUQvl5yV1OtuKWUwzV/OcUmkCcF6YaD/kHyZpHnx394KXxN3tuPa2iSMgB+LCaMxVC3eQ== X-Received: by 2002:a2e:9617:: with SMTP id v23mr2109450ljh.135.1606336481467; Wed, 25 Nov 2020 12:34:41 -0800 (PST) Received: from pc636 (h5ef52e3d.seluork.dyn.perspektivbredband.net. [94.245.46.61]) by smtp.gmail.com with ESMTPSA id 133sm45527lfe.300.2020.11.25.12.34.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Nov 2020 12:34:40 -0800 (PST) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Wed, 25 Nov 2020 21:34:38 +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: <20201125203438.GA7278@pc636> References: <20201117130434.GA10769@pc636> <20201118161623.GA21171@pc636> <87mtzeunsi.fsf@yhuang-dev.intel.com> <20201119173604.GA991@pc636> <87zh3cu578.fsf@yhuang-dev.intel.com> <20201123135919.GA12236@pc636> <875z5vtrsc.fsf@yhuang-dev.intel.com> <20201124164053.GA23686@pc636> <87o8jms1ed.fsf@yhuang-dev.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87o8jms1ed.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 Wed, Nov 25, 2020 at 08:52:58AM +0800, Huang, Ying wrote: > Uladzislau Rezki writes: > >> >> > - 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. > >> >> > >> >> Sorry, my original words weren't clear enough. What I really want to > >> >> suggest is to control the length of the purging list instead of reduce > >> >> lazy_max_pages() directly. That is, we can have a "atomic_t > >> >> nr_purge_item" to record the length of the purging list and start > >> >> purging if (vmap_lazy_nr > lazy_max_pages && nr_purge_item > > >> >> max_purge_item). vmap_lazy_nr is to control the virtual address space, > >> >> nr_purge_item is to control the batching purging latency. "100" is just > >> >> an example, the real value should be determined according to the test > >> >> results. > >> >> > >> > OK. Now i see what you meant. Please note, the merging is in place, so > >> > the list size gets reduced. > >> > >> Yes. In theory, even with merging, the length of the purging list may > >> become too long in some cases. And the code/algorithm changes that are > >> needed by controlling the length of the purging list is much less than > >> that are needed by merging. So I suggest to do length controlling > >> firstly, then merging. Again, just my 2 cents. > >> > > All such kind of tuning parameters work for one case and does not for > > others. Therefore i prefer to have something more generic that tends > > to improve the things, instead of thinking how to tune parameters to > > cover all test cases and workloads. > > It's a new mechanism to control the length of the purging list directly. > So, I don't think that's just parameter tuning. It's just a simple and > direct method. It can work together with merging method to control the > purging latency even if the vmap areas cannot be merged in some cases. > But these cases may not exist in practice, so I will not insist to use > this method. > No problem. I see your point about an extra thing to control the list length. Let's see if there are still complains from users. If we have such feedback, we will rework it further. Thanks! -- Vlad Rezki