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 1E5F3C433F5 for ; Thu, 17 Mar 2022 02:04:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8C6336B0071; Wed, 16 Mar 2022 22:04:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 874D98D0002; Wed, 16 Mar 2022 22:04:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 716AC8D0001; Wed, 16 Mar 2022 22:04:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0101.hostedemail.com [216.40.44.101]) by kanga.kvack.org (Postfix) with ESMTP id 5FAB26B0071 for ; Wed, 16 Mar 2022 22:04:02 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 0D33FA30BC for ; Thu, 17 Mar 2022 02:04:02 +0000 (UTC) X-FDA: 79252232724.24.F4C0987 Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) by imf18.hostedemail.com (Postfix) with ESMTP id A44761C0018 for ; Thu, 17 Mar 2022 02:04:00 +0000 (UTC) Received: by mail-pl1-f178.google.com with SMTP id n18so3298075plg.5 for ; Wed, 16 Mar 2022 19:04:01 -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=ZUrHaSdQj9PquKEUMEM9Xb4AyAVyoYlqVXVXozaoPAI=; b=fPjxLTmYhvqOtp/sQjU3H5TDfvaKf6tz8FJj6N+ajz5xQuCiumRq7FM1WWMCLYbBwG Wen60MDFoY04zkBVoDdUrXp7VvEIS4i8ns+9A5PIcoFxJlBiWkNeBne7xJ4pB2Dhmeud kjQy2Y53a2ADXCu+2kOy2LDG93fGh1GEgmJVnz1WIVJgr77cdq2IsBrKhee9ILOGBOas t7BanWBMNThbn9vbVueSNuuq2bdkx8oB+7Ch1c/KRxJjWi/7sBc2tI1oGJiLTSV1Z7eS aaD4PQZsk5NnUdWbLLWHHOTe8dedQSkrhEg7NB78nzf4Jq+peHX19uFhlc5oX3IiHL9U 8ipQ== 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=ZUrHaSdQj9PquKEUMEM9Xb4AyAVyoYlqVXVXozaoPAI=; b=rJ/+rr2OoJ/hlNpU+n7XO6aigVnbosA+caY80G2MRs5ThcJnaCGg9uuEvacJ36s6O0 lUmsIyYXQminiNDWlmLJpEp74oCqlpfbkFkqf5zhM8Ya1oyNCEciv1e89YW6KxUxiybR Ck23asENSdOHLMAtcj90hW7WfAopzj/CLr6QjLBDW9417NeLs1FPGksTCT5+2QUONp4a olyR1h4Vzpb8po3QNWXiPqU5fJqtJtDKugcDLJYBWkWO9QMP9s+tKScm0w2mnmzoIJTB ByBjHcliFdktA9znsAYuF3cOM70+qOonx3QNLmWch/P+0/iefWdSNJn0zwHkyVOAZDUw HA/w== X-Gm-Message-State: AOAM532ZHU2ZBb3jwPNlzF4Khd4qkYnSBIJI10Kba7HqaZWTihZKl589 ut/XCiE3LamG/hj0GMHl4Us= X-Google-Smtp-Source: ABdhPJy1GuquPEQNCp9zMrQe716lJ9/ZhpruJNY+Orkx3v1aluCewiaKiW5s80w13YLHRdaTKwx9Fw== X-Received: by 2002:a17:902:8ec7:b0:14a:c442:8ca2 with SMTP id x7-20020a1709028ec700b0014ac4428ca2mr2493858plo.12.1647482640368; Wed, 16 Mar 2022 19:04:00 -0700 (PDT) Received: from localhost ([193.203.214.57]) by smtp.gmail.com with ESMTPSA id z5-20020a056a00240500b004e15d39f15fsm4767133pfh.83.2022.03.16.19.03.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Mar 2022 19:03:59 -0700 (PDT) Message-ID: <6232970f.1c69fb81.4e365.c9f2@mx.google.com> X-Google-Original-Message-ID: <20220317020357.GA2135497@cgel.zte@gmail.com> Date: Thu, 17 Mar 2022 02:03:57 +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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <412dc01c-8829-eac2-52c7-3f704dbb5a98@redhat.com> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: A44761C0018 X-Stat-Signature: pj1ypu7rtz9jngsfxou1wa14cphmbjmu X-Rspam-User: Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=fPjxLTmY; spf=pass (imf18.hostedemail.com: domain of cgel.zte@gmail.com designates 209.85.214.178 as permitted sender) smtp.mailfrom=cgel.zte@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1647482640-81066 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, 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). > [...] > > > struct vm_area_struct *vma = vmf->vma; > > + vm_fault_t ret = 0; > > + bool delayacct = false; > > > > if (userfaultfd_pte_wp(vma, *vmf->pte)) { > > pte_unmap_unlock(vmf->pte, vmf->ptl); > > @@ -3294,7 +3296,11 @@ static vm_fault_t do_wp_page(struct vm_fault *vmf) > > * > > * PageKsm() doesn't necessarily raise the page refcount. > > */ > > - if (PageKsm(page) || page_count(page) > 3) > > + if (PageKsm(page)) { > > + delayacct = true; > > + goto copy; > > + } > > + if (page_count(page) > 3) > > goto copy; > > if (!PageLRU(page)) > > /* > > @@ -3308,7 +3314,12 @@ static vm_fault_t do_wp_page(struct vm_fault *vmf) > > goto copy; > > if (PageSwapCache(page)) > > try_to_free_swap(page); > > - if (PageKsm(page) || page_count(page) != 1) { > > + if (PageKsm(page)) { > > + delayacct = true; > > + unlock_page(page); > > + goto copy; > > + } > > + if (page_count(page) != 1) { > > unlock_page(page); > > goto copy; > > } > > @@ -3328,10 +3339,18 @@ static vm_fault_t do_wp_page(struct vm_fault *vmf) > > /* > > * Ok, we need to copy. Oh, well.. > > */ > > Why not simply check for PageKsm() here? I dislike the added complexity > above. > The original code check PageKsm() twice, I just try to keep the original semantics. If you think this patch is reasonable, I will try to find a better way to realize this. > > -- > Thanks, > > David / dhildenb