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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A5A18C433EF for ; Fri, 18 Mar 2022 01:41:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 08ED18D0002; Thu, 17 Mar 2022 21:41:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 03D7D8D0001; Thu, 17 Mar 2022 21:41:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E216A8D0002; Thu, 17 Mar 2022 21:41:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id CF9888D0001 for ; Thu, 17 Mar 2022 21:41:25 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 9DF0723F10 for ; Fri, 18 Mar 2022 01:41:25 +0000 (UTC) X-FDA: 79255804530.09.C9F315F Received: from mail-pg1-f172.google.com (mail-pg1-f172.google.com [209.85.215.172]) by imf17.hostedemail.com (Postfix) with ESMTP id 264BB4001D for ; Fri, 18 Mar 2022 01:41:25 +0000 (UTC) Received: by mail-pg1-f172.google.com with SMTP id o13so4010821pgc.12 for ; Thu, 17 Mar 2022 18:41:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:from:to:cc:subject:references:mime-version :content-disposition:in-reply-to; bh=lmtP1wcUmvhrUKL1qK3fWTAh+TjdYspAZPkSerDdS8Q=; b=heOGcLKGGj75wwn1TCFK8bz8KYJ/dqVSiMCw8Js3rcWA4Nzvq85RFmlaSv4SqUI1EF 2Hir2aq0+PVY0EtRM57KA9Jr9Pk3jWH0znpJUT5fYFNuB2QzK9t4XFlXLGPVENq13nRw HpRn2o+MqfVExYZDei0s6UKVjoQsV12QDhc7WO+e6s6zQbxOQUizy9c3m1VgbBf1xwt3 wIZHeS4hmlE87hthFUPF2Vfpa+w0b/KXQX/gJd/cV00TIP0LXVjRDRFDrgmf0PJvTMgv q6+EnHjbl6dAwM1whHD+TnYLxG5oTVQeOK9afqrPI8I1TsxUzKoUGP3vb7wFviEo7/Cb eRrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:from:to:cc:subject:references :mime-version:content-disposition:in-reply-to; bh=lmtP1wcUmvhrUKL1qK3fWTAh+TjdYspAZPkSerDdS8Q=; b=vcZCasr9X+tTmCeTr7Pfk/9z8j99tPoPa4+Fvh0kAc1JcczTYJ3vjXGFVe5E2vBbja NVeBzMPdpn6lRCcJRnDYRf3mS+4COXcEIRoeFL8wiSXbBDchtXGY58zGUzmW9c+RJKMb hzeVaR6xd0VqekfD6cys00ws5PTO6nzt63JyyhldkL6oSeljcQJHl1J5i1z5lHmqKZRJ kplgAR5fkabPPNrJax2jg5oGk71k5GFrCH9AmAEH/IWGnZtPnkldhqD9CPY7SKxX5dGZ 9A2zUofX8tLpRme5AlvDJF7dIa79SsUiWRxiV9NjMlb1HDBTejtQIVLAMmjs+/eWc9As uOFQ== X-Gm-Message-State: AOAM533BRo3sEJHugb+kGPXZCV2I63J8fbPCGtcCobUm6fWZ/dONXGjh ipGVTYc3euuCMg+IvAt2aPE= X-Google-Smtp-Source: ABdhPJypjKPw7hrzxmlCMsB/EhjFBBTvstwJLhSLSm0kv2K7xYnFlqK/THGz+ACZxGmL4pdD2WgnlA== X-Received: by 2002:a05:6a00:a2a:b0:4f7:68db:5e60 with SMTP id p42-20020a056a000a2a00b004f768db5e60mr7296975pfh.58.1647567684060; Thu, 17 Mar 2022 18:41:24 -0700 (PDT) Received: from localhost ([193.203.214.57]) by smtp.gmail.com with ESMTPSA id h13-20020a056a00170d00b004f757a795fesm8093309pfc.219.2022.03.17.18.41.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Mar 2022 18:41:22 -0700 (PDT) Message-ID: <6233e342.1c69fb81.692f.6286@mx.google.com> X-Google-Original-Message-ID: <20220318014121.GA2142378@cgel.zte@gmail.com> Date: Fri, 18 Mar 2022 01:41:21 +0000 From: CGEL To: David Hildenbrand Cc: bsingharora@gmail.com, akpm@linux-foundation.org, yang.yang29@zte.com.cn, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] delayacct: track delays from ksm cow References: <20220316133420.2131707-1-yang.yang29@zte.com.cn> <412dc01c-8829-eac2-52c7-3f704dbb5a98@redhat.com> <6232970f.1c69fb81.4e365.c9f2@mx.google.com> <4e76476b-1da0-09c5-7dc4-0b2db796a549@redhat.com> <62330402.1c69fb81.d2ba6.0538@mx.google.com> <987bd014-c5ab-52cb-627e-2085560cb327@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <987bd014-c5ab-52cb-627e-2085560cb327@redhat.com> X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 264BB4001D Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=heOGcLKG; spf=pass (imf17.hostedemail.com: domain of cgel.zte@gmail.com designates 209.85.215.172 as permitted sender) smtp.mailfrom=cgel.zte@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-Stat-Signature: g7jtm87ieni7spirq63ojjbfxdysw6zq X-HE-Tag: 1647567685-962409 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, Mar 17, 2022 at 11:05:22AM +0100, David Hildenbrand wrote: > On 17.03.22 10:48, CGEL wrote: > > On Thu, Mar 17, 2022 at 09:17:13AM +0100, David Hildenbrand wrote: > >> On 17.03.22 03:03, CGEL wrote: > >>> On Wed, Mar 16, 2022 at 03:56:23PM +0100, David Hildenbrand wrote: > >>>> On 16.03.22 14:34, cgel.zte@gmail.com wrote: > >>>>> From: Yang Yang > >>>>> > >>>>> Delay accounting does not track the delay of ksm cow. When tasks > >>>>> have many ksm pages, it may spend a amount of time waiting for ksm > >>>>> cow. > >>>>> > >>>>> To get the impact of tasks in ksm cow, measure the delay when ksm > >>>>> cow happens. This could help users to decide whether to user ksm > >>>>> or not. > >>>>> > >>>>> Also update tools/accounting/getdelays.c: > >>>>> > >>>>> / # ./getdelays -dl -p 231 > >>>>> print delayacct stats ON > >>>>> listen forever > >>>>> PID 231 > >>>>> > >>>>> CPU count real total virtual total delay total delay average > >>>>> 6247 1859000000 2154070021 1674255063 0.268ms > >>>>> IO count delay total delay average > >>>>> 0 0 0ms > >>>>> SWAP count delay total delay average > >>>>> 0 0 0ms > >>>>> RECLAIM count delay total delay average > >>>>> 0 0 0ms > >>>>> THRASHING count delay total delay average > >>>>> 0 0 0ms > >>>>> KSM count delay total delay average > >>>>> 3635 271567604 0ms > >>>>> > >>>> > >>>> TBH I'm not sure how particularly helpful this is and if we want this. > >>>> > >>> Thanks for replying. > >>> > >>> Users may use ksm by calling madvise(, , MADV_MERGEABLE) when they want > >>> save memory, it's a tradeoff by suffering delay on ksm cow. Users can > >>> get to know how much memory ksm saved by reading > >>> /sys/kernel/mm/ksm/pages_sharing, but they don't know what the costs of > >>> ksm cow delay, and this is important of some delay sensitive tasks. If > >>> users know both saved memory and ksm cow delay, they could better use > >>> madvise(, , MADV_MERGEABLE). > >> > >> But that happens after the effects, no? > >> > >> IOW a user already called madvise(, , MADV_MERGEABLE) and then gets the > >> results. > >> > > Image user are developing or porting their applications on experiment > > machine, they could takes those benchmark as feedback to adjust whether > > to use madvise(, , MADV_MERGEABLE) or it's range. > > And why can't they run it with and without and observe performance using > existing metrics (or even application-specific metrics?)? > > I think the reason why we need this patch, is just like why we need swap,reclaim,thrashing getdelay information. When system is complex, it's hard to precise tell which kernel activity impact the observe performance or application-specific metrics, preempt? cgroup throttle? swap? reclaim? IO? So if we could get the factor's precise impact data, when we are tunning the factor(for this patch it's ksm), it's more efficient. > -- > Thanks, > > David / dhildenb