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.6 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 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 E6319C388F9 for ; Tue, 17 Nov 2020 02:37:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4E3CB246B0 for ; Tue, 17 Nov 2020 02:37:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="tfvvnIha" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4E3CB246B0 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 43F9B6B0036; Mon, 16 Nov 2020 21:37:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3F2016B005D; Mon, 16 Nov 2020 21:37:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2BB476B0068; Mon, 16 Nov 2020 21:37:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id F00366B0036 for ; Mon, 16 Nov 2020 21:37:47 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 91A64180AD81F for ; Tue, 17 Nov 2020 02:37:47 +0000 (UTC) X-FDA: 77492349774.22.plane49_58136ea2732e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin22.hostedemail.com (Postfix) with ESMTP id 7270D18038E67 for ; Tue, 17 Nov 2020 02:37:47 +0000 (UTC) X-HE-Tag: plane49_58136ea2732e X-Filterd-Recvd-Size: 4002 Received: from mail-vs1-f68.google.com (mail-vs1-f68.google.com [209.85.217.68]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Tue, 17 Nov 2020 02:37:47 +0000 (UTC) Received: by mail-vs1-f68.google.com with SMTP id m16so10277257vsl.8 for ; Mon, 16 Nov 2020 18:37:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=skYHocM/r8tSdHIfpgnHgbHLY0K7ADsNgp1/uZHrUAw=; b=tfvvnIhahAtcu2NpB66Ww5oik9hOMvHo1B1hB5c5jtAhNRfW9ETAmJG1B2NWBsaRhc eyYsvziLYJ9zSF+RXjBV2BNufAbR3G0G6QR74wK/smzVP+5lp7KyvsyosnkOFuga2Ejx DYQnE3FFXgQPd5CXsaStwGHx4uJtdwLmdllLVzkpC8OutQ/sV70J3oNeo1z5hQSnLV0P T6HMKVrE5SI7aXRMakFS2j9Wv3wttEwkRyBjCkiUA5OQFSS3hQGBve+guDosG3mJXMEb 3vdOCmukYKLoDo5nzZJRED0iTgHZX0WVfF3xLYn+rJrf+NazRE+hhk+aLY+YBd4Jg4M5 DvLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=skYHocM/r8tSdHIfpgnHgbHLY0K7ADsNgp1/uZHrUAw=; b=Qugq8ByM1muQ4qkkPW91Iq1nQeaQKNIcN0tdkgWkjpgK1MLdqwId5GV42VjtoYqw+s eUaAt+nL6uVU90h8Fg3LsTN2VTURdXO2YfUBNPOPfmhg03rAAsbVXd+MECLTqxftZQeT l2E61gipaDXsjyLmf+PVZ1EYQfUVFd2QimkKgoc8/8HnfCebqUCZSlR7OoyahbkTMesD GMEJMea3/eIG2yw3Eo1cyJIo8YlyRnhCsnvw/pJJyYcL4AjlWKRpCXtmgQ61m90orkXs gYc2uP7l+akmfTwifVJ/D1SE3xvjUYvtBq6DOUIaisXGjsdkIoXuXy9+yOsXM/JulKs8 TfaQ== X-Gm-Message-State: AOAM531GNjU5P3+NTyD5vZxD5tbeve1ip7klMGPgu3mg4L23701AA+rJ S7QaYkq2Q/wtn+UIUOlFjZD6LtHH1Oo4URPZqvI= X-Google-Smtp-Source: ABdhPJzqkQX+5Yjpn7Om9ScJ4S8VaWEpKxvz2K8fap2Ovp0oTL/agSSoa9Ja2pnY7gv/Rb8oz8o5PU9qxmi+PtEH4nM= X-Received: by 2002:a05:6102:3c5:: with SMTP id n5mr10682563vsq.6.1605580666466; Mon, 16 Nov 2020 18:37:46 -0800 (PST) MIME-Version: 1.0 References: <20201116220033.1837-1-urezki@gmail.com> <20201116220033.1837-2-urezki@gmail.com> In-Reply-To: <20201116220033.1837-2-urezki@gmail.com> From: huang ying Date: Tue, 17 Nov 2020 10:37:34 +0800 Message-ID: Subject: Re: [PATCH 2/2] mm/vmalloc: rework the drain logic To: "Uladzislau Rezki (Sony)" Cc: Andrew Morton , linux-mm@kvack.org, LKML , Hillf Danton , Michal Hocko , Matthew Wilcox , Oleksiy Avramchenko , Steven Rostedt Content-Type: text/plain; charset="UTF-8" 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 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); If it works properly, the latency problem can be solved. Can you check whether this doesn't work for you? Best Reagrds, Huang, Ying