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=-15.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=ham 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 041ACC2B9F7 for ; Fri, 28 May 2021 17:14:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 82D1D613D1 for ; Fri, 28 May 2021 17:14:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 82D1D613D1 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 239556B0073; Fri, 28 May 2021 13:14:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1EA6B6B0074; Fri, 28 May 2021 13:14:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 03C606B0075; Fri, 28 May 2021 13:14:02 -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 C5E996B0073 for ; Fri, 28 May 2021 13:14:02 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 6ADC8C5B0 for ; Fri, 28 May 2021 17:14:02 +0000 (UTC) X-FDA: 78191287524.05.DCD2201 Received: from m43-7.mailgun.net (m43-7.mailgun.net [69.72.43.7]) by imf08.hostedemail.com (Postfix) with ESMTP id BBFE68019EA8 for ; Fri, 28 May 2021 17:13:48 +0000 (UTC) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1622222042; h=Content-Transfer-Encoding: Content-Type: In-Reply-To: MIME-Version: Date: Message-ID: From: References: Cc: To: Subject: Sender; bh=68ZmfhGkhVwi8fpXi4ry64nVPiXvOTjsPddpfCAGMtI=; b=SXQy4VSj4AkgHWS41d0zBitQtN0MBdglfXEerDtMEuY7aUCnOWhIe49lGL5K95Yx3WJ15L/E oVm/Q/B1+DMHnvR7gz2jOcKkXxrewaoWc4TmNhApsmN/+8pfP2PUAYv5OwLjKVVA97VyR/9X /6TDCAS7WWKMnon29dPLDZQuK2I= X-Mailgun-Sending-Ip: 69.72.43.7 X-Mailgun-Sid: WyIwY2Q3OCIsICJsaW51eC1tbUBrdmFjay5vcmciLCAiYmU5ZTRhIl0= Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n03.prod.us-west-2.postgun.com with SMTP id 60b1221db7e6c05f95dec2e2 (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Fri, 28 May 2021 17:02:21 GMT Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 5C0C2C43217; Fri, 28 May 2021 17:02:21 +0000 (UTC) Received: from [192.168.29.110] (unknown [49.37.158.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: charante) by smtp.codeaurora.org (Postfix) with ESMTPSA id 6DB24C433D3; Fri, 28 May 2021 17:02:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 6DB24C433D3 Subject: Re: [PATCH V2] mm: compaction: support triggering of proactive compaction by user To: Vlastimil Babka , akpm@linux-foundation.org, mcgrof@kernel.org, keescook@chromium.org, yzaikin@google.com, nigupta@nvidia.com, bhe@redhat.com, mateusznosek0@gmail.com, sh_def@163.com, iamjoonsoo.kim@lge.com, vinmenon@codeaurora.org Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Linux API References: <1621345058-26676-1-git-send-email-charante@codeaurora.org> From: Charan Teja Kalla Message-ID: <461d3bb1-abed-e6e5-d924-44b4a9243e60@codeaurora.org> Date: Fri, 28 May 2021 22:32:12 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=mg.codeaurora.org header.s=smtp header.b=SXQy4VSj; spf=pass (imf08.hostedemail.com: domain of bounce@mg.codeaurora.org designates 69.72.43.7 as permitted sender) smtp.mailfrom=bounce@mg.codeaurora.org; dmarc=none X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: BBFE68019EA8 X-Stat-Signature: 386hso3e8tkmsft6y96yyjw7ujxqjdwb X-HE-Tag: 1622222028-722936 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: Thanks Vlastimil for your inputs!! On 5/28/2021 8:49 PM, Vlastimil Babka wrote: > On 5/18/21 3:37 PM, Charan Teja Reddy wrote: >> The proactive compaction[1] gets triggered for every 500msec and run >> compaction on the node for COMPACTION_HPAGE_ORDER (usually order-9) >> pages based on the value set to sysctl.compaction_proactiveness. >> Triggering the compaction for every 500msec in search of >> COMPACTION_HPAGE_ORDER pages is not needed for all applications, >> especially on the embedded system usecases which may have few MB's of >> RAM. Enabling the proactive compaction in its state will endup in >> running almost always on such systems. >> This triggering of proactive compaction is done on a write to >> sysctl.compaction_proactiveness by user. >> >> [1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=facdaa917c4d5a376d09d25865f5a863f906234a >> >> Signed-off-by: Charan Teja Reddy > Cancelling all current sleeps immediately when the controlling variable changes > doesn't sound wrong to me. Agree that cancelling sleeps is not wrong here. > A question below: > >> --- >> changes in V2: >> - remove /proc interface trigger for proactive compaction >> - Intention is same that add a way to trigger proactive compaction by user. >> if (proactive_defer) { >> proactive_defer--; >> - continue; >> + goto loop; > I don't understand this part. If we kick kcompactd from the sysctl handler > because we are changing proactiveness, shouldn't we also discard any accumulated > defer score? Yes, we should be discarding the accumulated defer score when user changing the proactiveness, even when writing higher proactiveness value than for which it was deferred. Will raise V3 for this. > --Charan -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Projec t