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 3643DC77B70 for ; Mon, 17 Apr 2023 14:28:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 814A78E0001; Mon, 17 Apr 2023 10:28:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7C4ED6B0075; Mon, 17 Apr 2023 10:28:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 68D378E0001; Mon, 17 Apr 2023 10:28:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 53E856B0074 for ; Mon, 17 Apr 2023 10:28:47 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 0B571120595 for ; Mon, 17 Apr 2023 14:28:47 +0000 (UTC) X-FDA: 80691114294.26.5E9B99B Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by imf29.hostedemail.com (Postfix) with ESMTP id E882012001F for ; Mon, 17 Apr 2023 14:28:44 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=E88g1SN+; spf=pass (imf29.hostedemail.com: domain of dianders@chromium.org designates 209.85.218.49 as permitted sender) smtp.mailfrom=dianders@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681741725; a=rsa-sha256; cv=none; b=XsY+4eRdDcQvwekx3RLQ7M82zhIPG4ZBbwyaM47zMM7SeSX/kMpyN8qOZorYS1mXGqOfvT lUIC7zmMGp9TOuuJOYk7rVqFnfz9HzcAbYBEwLXcXGYoKQnoWzPPEdfKLkMCoOtRkpcjlJ +x1KM0MgjwbIilStroIlTyl+r+7SZeI= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=E88g1SN+; spf=pass (imf29.hostedemail.com: domain of dianders@chromium.org designates 209.85.218.49 as permitted sender) smtp.mailfrom=dianders@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681741725; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=yrJp/BsBrfAzaGece7i1JSZGw1d/TlwbKCb/n0TBQoo=; b=Y/Jc2Ki/0NsjDHlw5diyXkCS2LxYv2wW6Ax0JQ4LoFK5v2YWIJxjUfmYCFfCaZCD+WMCal ad2od87/USeLWL6gDYJj4e+ELPvwp9VLZn5tb5OJP2YKsZKRMfx6k5xelkkfB4VSENyknz abvHrHyTGT+hBNOpi3sb/gt6LN17bHU= Received: by mail-ej1-f49.google.com with SMTP id dx24so20616941ejb.11 for ; Mon, 17 Apr 2023 07:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1681741722; x=1684333722; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=yrJp/BsBrfAzaGece7i1JSZGw1d/TlwbKCb/n0TBQoo=; b=E88g1SN+xajbXIX3KHWTh2EeuVsSBdRto4KlgR4r2YOVvmg6Rs54lkNFnRD/XePwGz KSYesexLsEOD5iO3uRprLuMlZ1+oRrKbekkNKknh/M/XnA4mkbSa25ef+No3MxBonPw1 f3zVa6Sw2ctjb8ZaTgcgajp9uDpv9M68kMvh0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681741722; x=1684333722; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=yrJp/BsBrfAzaGece7i1JSZGw1d/TlwbKCb/n0TBQoo=; b=TokSos/DMz/cvC5ihJlD8rUtR3xUFDWHAsIaYnFSgvthL0aRTX18yY90l2ALy/kXov C/XoG/dVgDp1sGTN7LPI6G5f0rJkDY0T9BATkhomdU6tC3wfDt9KX3bzDlW2OnaTuM+b sG35ihQlbBK+IDy8H+Xv9pHpBEqv5OqhOO3bIqviuSDyorUJywGUUVzwg5lAabTiHKkl cZ124LLdfPwXIqfW8LPOjl0xrlJ/90gG66XZHCkC0wJGu3FjwJBD7Aqpc6DBC0/s0CLJ nf/QLSjbI1+eS15/+BaPvlHKTHLw/DcWR9YHtA5OEr3CwD8IxUqEVzlfAuJ5Zc5efC68 XfXA== X-Gm-Message-State: AAQBX9fHc7NuKKeVtCIuBC9Teawpi6VpmTiv1Zmp4P826q5Gnjmamfbq QudO3wxYb1x2FBUjZDN7Y9RjHKLliQPDcpcHvZQ/e/H3 X-Google-Smtp-Source: AKy350YXZQTZiE3rUo01f2AZZ9OD3JsixCcQIOF3h+0RTYN/b7N6C3DQnj3ixZvFrU6pY0lUKrkOlA== X-Received: by 2002:a17:906:6494:b0:94f:8605:3f31 with SMTP id e20-20020a170906649400b0094f86053f31mr2127096ejm.42.1681741721886; Mon, 17 Apr 2023 07:28:41 -0700 (PDT) Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com. [209.85.128.50]) by smtp.gmail.com with ESMTPSA id vv5-20020a170907a68500b008cecb8f374asm6658995ejc.0.2023.04.17.07.28.41 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Apr 2023 07:28:41 -0700 (PDT) Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-3f09a3c8bbbso9476205e9.0 for ; Mon, 17 Apr 2023 07:28:41 -0700 (PDT) X-Received: by 2002:adf:e0ca:0:b0:2f5:9146:700f with SMTP id m10-20020adfe0ca000000b002f59146700fmr980814wri.11.1681741720976; Mon, 17 Apr 2023 07:28:40 -0700 (PDT) MIME-Version: 1.0 References: <20230413182313.RFC.1.Ia86ccac02a303154a0b8bc60567e7a95d34c96d3@changeid> <87v8hz17o9.fsf@yhuang6-desk2.ccr.corp.intel.com> <87ildvwbr5.fsf@yhuang6-desk2.ccr.corp.intel.com> In-Reply-To: <87ildvwbr5.fsf@yhuang6-desk2.ccr.corp.intel.com> From: Doug Anderson Date: Mon, 17 Apr 2023 07:28:28 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH] migrate_pages: Never block waiting for the page lock To: "Huang, Ying" Cc: Andrew Morton , Yu Zhao , linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: E882012001F X-Rspamd-Server: rspam01 X-Stat-Signature: zpy4joeq1949jfpfrqstnuq3iac6y976 X-HE-Tag: 1681741724-866853 X-HE-Meta: U2FsdGVkX18H0W3RviSm5WhMBijBJscdKf0C9v80rsxIkhQBJbHVkG+ip+YghyeynHrghLcZhFLD7H+GVLcYD85kNR2O0PozpSaDIrZGMK2if0nbE3KmvrK546Q3er3T5YVV7gvMV8RjGCkeNhbtsSNnlbqeb0KI2emKu91T8fQG2XCNWgg7xnAV53++BSpPdcv5TvUi8hYvcryuO5+7NVVLpyLVrN+9lilJbmQDz5SazNANtEON5ygAk5Vnuolj4K/RgLa5HQwN0DMbYhS56oNJ5WhXg40OuFKvI0TRmSWjXvO3bTPYdtC0665uFesJDGf0ZGvXC6u2uZx1zVAbLgNnyjxog2ZcutxNMLm+u8Jf0PS9i/+MW2p5m1UMS7jsVPId0/fQya3mRgk5+ai4oCBg2MjTM/Yiavn/coz7tp89h6VAXmQsA8msVhm3mIkihoR3h7NvlawzdInOzJJddcG2a2pmU7Vc3EMdcOj5geNPSQBqBIwufmU/NmbVrtbar2ODOyVdghqJgL9A/TonAVEHm7pet+pWodRb7zoiQ6sWuqAS2RGT3rF1oHpXZJKcThV0q08A/SJyTl7N/PRIbuJtaYrex1g2+0v4TKK+cwfkFHX4S8JFkcyDXvszJCBnywn76vVSOWEWtssqGWkXqgyAIz8LV15qWllOziP3WoGiCNsSkS8Z6PbloB+Tb7ryG8Vr206lzQB9RYVo/t53HC0HVw5CCRCiaA61qjlrGoTeY0l+10q28Cvna8Y+01J9/WvLLsyMVa0+LEb6sEdUCXO5JOD0n7+SlcqNluy0X26epq/+PPPVHxRwNiRiXz4ut410VLwoGt8SM/Gyw+jalXKefvZzkKTUO3gojxmnE+RECCd+pbBwkzDxVaO9Gzq85wEKQimfFE/Wb/fQPc06Pq0WAfFEdVo5cgWhS1lB8IZJq8cl1GtSebPS2RiOce3WIPcY0dhQxT29qAkEDmv ciWOVfd3 FmQLqNyAtZoeBhb+gzUf7KO9CJeS6g0HHk8KzGfHPIHdC6bkRTUZuaRELkba9QvW1QpQ/8TQbZS6L0bcC5mzxoG0CwMFVnNw9KE3IMWN6UN9FuGtw/mjfqfTboJIPhR4YOsHANWOf8b9JioLYYChhsP9DDz+N081vcD0t2b3UjjHY6G1eRVVuk2SvVeK+7NIlJp3hiaJPhZpcT4PZnClJfIYnWfL8XrwiT5mxI1bhRKGJJ9xgj3HkN6RkCNbOGeyfDiiFMNhFqf88dRf2A4UhkJWgTVvDUVeest9EmkakA7B8uuqrDLeqBC/FAWNqAZZKQSN4msHcN4AwkTfaWmgtl0ftK1pnlFGdLZX/tsOL/pI0WWdp8jrPeEPYGjOsmjA3aPHVp8/C0VL0wnqJL+jVlahDcRbeklH9eYziuBSiu4s7Ha14WGr+QFzQwKUpmKdyfDoO 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: Hi, On Sun, Apr 16, 2023 at 6:15=E2=80=AFPM Huang, Ying = wrote: > > Doug Anderson writes: > > > Hi, > > > > On Thu, Apr 13, 2023 at 8:10=E2=80=AFPM Huang, Ying wrote: > >> > >> Douglas Anderson writes: > >> > >> > Currently when we try to do page migration and we're in "synchronous= " > >> > mode (and not doing direct compaction) then we'll wait an infinite > >> > amount of time for a page lock. This does not appear to be a great > >> > idea. > >> > > >> > One issue can be seen when I put a device under extreme memory > >> > pressure. I took a sc7180-trogdor Chromebook (4GB RAM, 8GB zram > >> > swap). I ran the browser along with Android (which runs from a > >> > loopback mounted 128K block-size squashfs "disk"). I then manually r= an > >> > the mmm_donut memory pressure tool [1]. The system is completely > >> > unusable both with and without this patch since there are 8 processe= s > >> > completely thrashing memory, but it was still interesting to look at > >> > how migration was behaving. I put some timing code in and I could se= e > >> > that we sometimes waited over 25 seconds (in the context of > >> > kcompactd0) for a page lock to become available. Although the 25 > >> > seconds was the high mark, it was easy to see tens, hundreds, or > >> > thousands of milliseconds spent waiting on the lock. > >> > > >> > Instead of waiting, if I bailed out right away (as this patch does),= I > >> > could see kcompactd0 move forward to successfully to migrate other > >> > pages instead. This seems like a better use of kcompactd's time. > >> > > >> > Thus, even though this didn't make the system any more usable in my > >> > absurd test case, it still seemed to make migration behave better an= d > >> > that feels like a win. It also makes the code simpler since we have > >> > one fewer special case. > >> > >> TBH, the test case is too extreme for me. > > > > That's fair. That being said, I guess the point I was trying to make > > is that waiting for this lock could take an unbounded amount of time. > > Other parts of the system sometimes hold a page lock and then do a > > blocking operation. At least in the case of kcompactd there are better > > uses of its time than waiting for any given page. > > > >> And, we have multiple "sync" mode to deal with latency requirement, fo= r > >> example, we use MIGRATE_SYNC_LIGHT for compaction to avoid too long > >> latency. If you have latency requirement for some users, you may > >> consider to add new "sync" mode. > > > > Sure. kcompactd_do_work() is currently using MIGRATE_SYNC_LIGHT. I > > guess my first thought would be to avoid adding a new mode and make > > MIGRATE_SYNC_LIGHT not block here. Then anyone that truly needs to > > wait for all the pages to be migrated can use the heavier sync modes. > > It seems to me like the current users of MIGRATE_SYNC_LIGHT would not > > want to block for an unbounded amount of time here. What do you think? > > It appears that you can just use MIGRATE_ASYNC if you think the correct > behavior is "NOT block at all". I found that there are more > fine-grained controls on this in compaction code, please take a look at > "enum compact_priority" and its comments. Actually, the more I think about it the more I think the right answer is to keep kcompactd as using MIGRATE_SYNC_LIGHT and make MIGRATE_SYNC_LIGHT not block on the folio lock. kcompactd can accept some blocking but we don't want long / unbounded blocking. Reading the comments for MIGRATE_SYNC_LIGHT, this also seems like it fits pretty well. MIGRATE_SYNC_LIGHT says that the stall time of writepage() is too much. It's entirely plausible that someone else holding the lock is doing something as slow as writepage() and thus waiting on the lock can be just as bad for latency. I'll try to send out a v2 with this approach today and we can see what people think. -Doug