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=-13.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 01D9BC49EA5 for ; Thu, 24 Jun 2021 14:43:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8E64C613EB for ; Thu, 24 Jun 2021 14:42:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8E64C613EB Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 691906B0036; Thu, 24 Jun 2021 10:42:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 61B346B005D; Thu, 24 Jun 2021 10:42:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 46DA96B006C; Thu, 24 Jun 2021 10:42:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0132.hostedemail.com [216.40.44.132]) by kanga.kvack.org (Postfix) with ESMTP id 1217F6B0036 for ; Thu, 24 Jun 2021 10:42:58 -0400 (EDT) Received: from smtpin39.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 3B6C9181D6070 for ; Thu, 24 Jun 2021 14:42:58 +0000 (UTC) X-FDA: 78288884436.39.36424BE Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) by imf25.hostedemail.com (Postfix) with ESMTP id D94C86000156 for ; Thu, 24 Jun 2021 14:42:57 +0000 (UTC) Received: by mail-lf1-f46.google.com with SMTP id a15so2918515lfr.6 for ; Thu, 24 Jun 2021 07:42:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zPDOtaL+XLEb4/llfBA4wK0O+KTaocWklfCim100ic0=; b=AwNSCHRt5qjpDmU6yijGBadrKOXnnr9hVNiLlx/FbaOFqI7Oxqf65VBlsJ84NPRVUf Uk6MvF+XRWYMyea/gmTHmIUsLYO7xcwg9uhua6HSTwUNSWCMFDs8TG7TzLmj03SLlMLu nm+U/p9FibYIcXKi7fSqx93PopR7gtjTiBZHR3bsaYo0FD2sFQhJS5DGD3A8rJJh5InC +SOGjQ6qrQ/au6Oy7sPYBw1TPZPaqdfRUaAmVvuVuXWe2YEZ5fRR/HxaJPTbhGqJHLGE N1zbWFHepM00ofYSoqSVnrlyxnmfStngqHMx949hyPQtNpJz+7vR6NuPH/uXYf1W6sge jWiw== 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=zPDOtaL+XLEb4/llfBA4wK0O+KTaocWklfCim100ic0=; b=M90biALUY7QnybAHsFCO4G6d8DzyeB4ibCYaSx2b5Uw++fKmpaL1a04EmxJG5CYuUH Dhv4TOqXYdoLtfHTWWP+y+r/4QEHpzrsEBM+BNjxLFDYC/KyLwK1NgmWFDpMjn0COXVd vgNd12LchWL1vsb0TNpqpQZ1LlNouxoT2+ewHmiTVOkaDUQtlLvTozeSMg8B/doA4QrL wPpnbkB18BPvskKN56A8VrDOdZonJDQbgFqjk486wsQP3FU2VTvtLIgQ8cfb0v33hv5/ NcyXO2gJl2T4QQLJhzrPTVWPxJx1MR1JgQGx1hDohulCetv0GmXhhA/xpaPCzcwQti45 jBpg== X-Gm-Message-State: AOAM532kBMFwtVSm31qm4bjQKaQYagGYh6kv1LG4RFORoXBytyHwjcxB YwVL0Psm1DBbYXZz56YxQq8AQ+7+DXSRMc2A7uaz/A== X-Google-Smtp-Source: ABdhPJz9FhxmntnQWK4wpCGRR5Ld+FnwOhzVQjZ+p6hzlK1H8jz79mEJvtqeIDnDWjY+USditIlEcEmoOoq3XuphUdY= X-Received: by 2002:a05:6512:3155:: with SMTP id s21mr4064815lfi.358.1624545776093; Thu, 24 Jun 2021 07:42:56 -0700 (PDT) MIME-Version: 1.0 References: <20210624102623.24563-1-sjpark@amazon.de> <20210624102623.24563-3-sjpark@amazon.de> In-Reply-To: <20210624102623.24563-3-sjpark@amazon.de> From: Shakeel Butt Date: Thu, 24 Jun 2021 07:42:44 -0700 Message-ID: Subject: Re: [PATCH v31 05/13] mm/damon: Implement primitives for the virtual memory address spaces To: SeongJae Park Cc: SeongJae Park , Jonathan.Cameron@huawei.com, acme@kernel.org, alexander.shishkin@linux.intel.com, amit@kernel.org, benh@kernel.crashing.org, Brendan Higgins , Jonathan Corbet , David Hildenbrand , dwmw@amazon.com, Marco Elver , "Du, Fan" , foersleo@amazon.de, greg@kroah.com, Greg Thelen , guoju.fgj@alibaba-inc.com, jgowans@amazon.com, Mel Gorman , mheyne@amazon.de, Minchan Kim , Ingo Molnar , namhyung@kernel.org, "Peter Zijlstra (Intel)" , Rik van Riel , David Rientjes , Steven Rostedt , Mike Rapoport , Shuah Khan , sieberf@amazon.com, snu@zelle79.org, Vlastimil Babka , Vladimir Davydov , zgf574564920@gmail.com, linux-damon@amazon.com, Linux MM , linux-doc@vger.kernel.org, LKML Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=AwNSCHRt; spf=pass (imf25.hostedemail.com: domain of shakeelb@google.com designates 209.85.167.46 as permitted sender) smtp.mailfrom=shakeelb@google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: q3ydgr395xbapt3h5qks7ekoquzoojye X-Rspamd-Queue-Id: D94C86000156 X-Rspamd-Server: rspam06 X-HE-Tag: 1624545777-198152 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, Jun 24, 2021 at 3:26 AM SeongJae Park wrote: > [...] > > > +/* > > > + * Get the three regions in the given target (task) > > > + * > > > + * Returns 0 on success, negative error code otherwise. > > > + */ > > > +static int damon_va_three_regions(struct damon_target *t, > > > + struct damon_addr_range regions[3]) > > > +{ > > > + struct mm_struct *mm; > > > + int rc; > > > + > > > + mm = damon_get_mm(t); > > > + if (!mm) > > > + return -EINVAL; > > > + > > > + mmap_read_lock(mm); > > > + rc = __damon_va_three_regions(mm->mmap, regions); > > > + mmap_read_unlock(mm); > > > > This is being called for each target every second by default. Seems > > too aggressive. Applications don't change their address space every > > second. I would recommend to default ctx->primitive_update_interval to > > a higher default value. > > Good point. If there are many targets and each target has a huge number of > VMAs, the overhead could be high. Nevertheless, I couldn't find the overhead > in my test setup. Also, it seems someone are already started exploring DAMON > patchset with the default value. and usages from others. Silently changing the > default value could distract such people. So, if you think it's ok, I'd like > to change the default value only after someone finds the overhead from their > usages and asks a change. > > If you disagree or you found the overhead from your usage, please feel free to > let me know. > mmap lock is a source contention in the real world workloads. We do observe in our fleet and many others (like Facebook) do complain on this issue. This is the whole motivation behind SFP, maple tree and many other mmap lock scalability work. I would be really careful to add another source of contention on mmap lock. Yes, the user can change this interval themselves but we should not burden them with this internal knowledge like "oh if you observe high mmap contention you may want to increase this specific interval". We should set a good default value to avoid such situations (most of the time).