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 24DF6C77B61 for ; Fri, 14 Apr 2023 01:23:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 59D18900003; Thu, 13 Apr 2023 21:23:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 54D05900002; Thu, 13 Apr 2023 21:23:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 41534900003; Thu, 13 Apr 2023 21:23:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 310F4900002 for ; Thu, 13 Apr 2023 21:23:49 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id F0BB81C6057 for ; Fri, 14 Apr 2023 01:23:48 +0000 (UTC) X-FDA: 80678249736.30.5DAD082 Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by imf10.hostedemail.com (Postfix) with ESMTP id 29A49C000E for ; Fri, 14 Apr 2023 01:23:46 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=ih5QBKpf; spf=pass (imf10.hostedemail.com: domain of dianders@chromium.org designates 209.85.214.172 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=1681435427; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=ySd2AFOBGRafkZnqoRaWZ+CuGXqcsO86v2c2mbNKCt0=; b=iU9eue2GH5faAlot1Q8/qXVWXIS0FX8wNTBg+j9rurWHKB7UWzsVJdEFI/vYyaMt1JNsDC AjilcHQvTfHtX6txItHnCkZyYIAvD06oSuG1XLQYafenpi02wXNKFjYCtWRK0ga7EdO+Dd 09nDU0tmvnOvwintr12CgEsFHVikhLg= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=ih5QBKpf; spf=pass (imf10.hostedemail.com: domain of dianders@chromium.org designates 209.85.214.172 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=1681435427; a=rsa-sha256; cv=none; b=PVXhe6UHDYvpH1+oPT95hMaCOY+0S3VcLw7eBUs55+jnPlrdhSMZNJylaG9M+O3VSiGZhq Ul6fOk7DBdN728Jije3teR0MootXlt6rGPq7mMC6sPAh5HNT8DlAqup12Ii5NM4gzj8Z4G rxBCsZLmmsV6NhnLYamIEh1I2rUtBSo= Received: by mail-pl1-f172.google.com with SMTP id 21so8736986plg.12 for ; Thu, 13 Apr 2023 18:23:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1681435426; x=1684027426; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=ySd2AFOBGRafkZnqoRaWZ+CuGXqcsO86v2c2mbNKCt0=; b=ih5QBKpfh12zgAWpWZBSYoZ5iClOskNaxjN6FS5ohodztZdxKJmIOjzVQN4ewzvb00 WqfzUppOQ+yz46+81FK2uJRQKTUVrTx4O0h3u8sb2EnDwb7538qU6Dt7G0PENasO5cD/ J0zRcM1HQVTloF2a4UTsA7ZP8KMzUvwIM9H9U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681435426; x=1684027426; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ySd2AFOBGRafkZnqoRaWZ+CuGXqcsO86v2c2mbNKCt0=; b=L7w1TZH/QxmtYNRWSUAIKXk23ptVeU4i6Fpby24QvdVtOEL2zxJFCr4Mc8qwO4hYuR rZwaPhoOU8db54NsxrCeE26QbWmVao0HbUfcZqwr7ZfMie1oGxVILlcP8ON1YhvSv3CF LLIGyEn2MmNyc7evZQVqt3z/vQpQdKDsloBVRj7+CzQ0LPLKkAOy6UdRIt5MxmyRDtf3 MKmgCKt20a8k8ilEQsnZ8j0Y3Auw7ECZI3Tv5rK6mAiRchR5PE8Wy/une901fhONSwso dfgjmFWYlnYORHV2BrdGTeaxm+Qcth5hVsSJUrYuDCDWbglqsIYbmpFs9yC2xxXY3Fgx KUgg== X-Gm-Message-State: AAQBX9fnSUdOZrOuaD3kkT26gw0BczqOCkiIj1CsqHDKxHShZv1jA1rU tRs275G3OuB12FPiY3HFV1ZHtw== X-Google-Smtp-Source: AKy350Zm5gG5OUvroOMZO/PsbzsD1hKld53c1Zd20J6JpXSN+Llq7B3hHMCcHJeq+UjGi/MyKpJy2g== X-Received: by 2002:a17:902:d902:b0:1a6:47aa:dbd7 with SMTP id c2-20020a170902d90200b001a647aadbd7mr934051plz.53.1681435425851; Thu, 13 Apr 2023 18:23:45 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:9d:2:d555:e8ef:b29c:bd37]) by smtp.gmail.com with ESMTPSA id t20-20020a170902d21400b001a05122b562sm2022886ply.286.2023.04.13.18.23.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Apr 2023 18:23:45 -0700 (PDT) From: Douglas Anderson To: Andrew Morton Cc: Yu Zhao , Douglas Anderson , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [RFC PATCH] migrate_pages: Never block waiting for the page lock Date: Thu, 13 Apr 2023 18:23:15 -0700 Message-ID: <20230413182313.RFC.1.Ia86ccac02a303154a0b8bc60567e7a95d34c96d3@changeid> X-Mailer: git-send-email 2.40.0.634.g4ca3ef3211-goog MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Stat-Signature: phh6tyhks6sbsg3j9cfxaqgza4g4fgg4 X-Rspam-User: X-Rspamd-Queue-Id: 29A49C000E X-Rspamd-Server: rspam06 X-HE-Tag: 1681435426-298937 X-HE-Meta: U2FsdGVkX18QX2tM8evdK1WzmhyYWjs2uJmwbltmrU3RuPwKBVdk903obj8Jzomho9Fyw+MzutnS2XK6tvclYS9CE+peoFB49nCks2BgAiq4EvB5SFoaKyyCbt+jaCHGoTQn7tP3ggfoPZ7urn9OLKkm9DSbaVTV98/+au5ixt3mtc7ZmWIMug55GouWWXZa1czNtz9QliVWcGvdu7C1EX+WWTLRGGYffk1O1ypizHQVA5CsCOgC+JvkpPYq52LMR83m4tj+FNGF/UcLyXlbDNe07ebfGDg3A/AvY4ttvZjfQdI/Wu8gXWtHgcFE7rteRv9vz6OOwXVG+MuvqtGVISDqZ9934sB1aJUbSv+tET3K5qGGmje89tIVu0dNN0OiKv2WqAgtx7TsoQvOy6yWUtQwmaPF1J7iX0bGT4sbhm/kvZD/OuGvvXtODOv9huCiDjOse811J0R5OoexKmksuv2/vHCxZ+Q2V+Qrx5tgC0c4pBxOBfkEmq7k8FhNpxnE7k0NqYxxHc6FgAOkT7MrrodZqVmREbsD2LOvNBkvCqRYUpdHMc+GY5MarFb6sohUHA+ewZAdSTG/s6M8yzJwRdScCnL7e+f9hhIdEgPjCLUCiRy+ZcQgkY6mr4kCpoM8RUDpNmedOQ4FWNdXAK2PDITHvMIRzu78AtajF7fvX0XUTQCbTejeqqbzwUW0lQ8W7pHJ8qhsJ6Ct49wLYh9hMNW1np9ebd3eXwIDf09EZsxkDTSB5qiirXkaVx2mDYhpUQf3dFKyxmyXD03gjUehHgNVq9boz0lmGV8HH/if+NijTIJn4Vp2+/EMYKj/uxj+NNqqMoVxN75hzDbvKHFOD30bn6w0Dy+3i8Ft3ZQxOhoZigAgrZzm+tgDspAVsb7j/ekT/sXtJAkTZc9UVp4MH2inxwJdkf3YGcQu1EbnwobOd+bnaWGqCceGoNbB9IyD62ElLoSQ+TYmFxhKShJ HKf1pQ7W z3DrC+dspRG+dtWVZLI+FCtPXTuEHfG5RYKw2ORLAeI7dSxW2q91SYecHyIEs+wCvA2Ozr8HF5bcf8o1vRa50fzZ7FGVbuDu8OPTqCB7YpFKNHCc/0dLichn83pmaTeyhmY8P79mfnWgownKH2rh9s8EnzUNlqXFFKh0+NVHRvxWZvLuDJvQx29RTSIkExRG34p+LIEZU6NehRaH33WLPbOM1oqDn4uhtnNA7LcCRNwRJgnHdvdOpD8FxmE3kPXQdmFO2eY3k5yNrojwqbxdFZCNm05JNHbj0ASr1bKb+OpGjkCFiDUSSwcextEMX+3MUwieLfDEH02Cif8yPVG3Y7O5t7e4sBzVgn+rX0IowG3s/QSYnVusLuXW72QTQMvOGP/37W8lPzY8lV6U53XtXNF582L6ac/fo5esY/3NBRJCv7sqKtoLUelB5qhkooekRCi7qONg+ww4pTUuv5NYLt21BybRi6STgzZecipGiSVsl1jDEoD2tJ+JzOMsKeZzWbpo8FhJenGbRiEImP4SUBKHVnw== 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: 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 ran the mmm_donut memory pressure tool [1]. The system is completely unusable both with and without this patch since there are 8 processes completely thrashing memory, but it was still interesting to look at how migration was behaving. I put some timing code in and I could see 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 and that feels like a win. It also makes the code simpler since we have one fewer special case. The second issue that this patch attempts to fix is one that I haven't managed to reproduce yet. We have crash reports from the field that report that kcompactd0 was blocked for more than ~120 seconds on this exact lock. These crash reports are on devices running older kernels (5.10 mostly). In most of these crash reports the device is under memory pressure and many tasks were blocked in squashfs code, ext4 code, or memory allocation code. While I don't know if unblocking kcompactd would actually have helped relieve the memory pressure, at least there was a chance that it could have helped a little bit. [1] https://chromium.googlesource.com/chromiumos/platform/microbenchmarks/+/refs/heads/main/mmm_donut.py Signed-off-by: Douglas Anderson --- mm/migrate.c | 25 +++++++------------------ 1 file changed, 7 insertions(+), 18 deletions(-) diff --git a/mm/migrate.c b/mm/migrate.c index db3f154446af..dfb0a6944181 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -1143,26 +1143,15 @@ static int migrate_folio_unmap(new_page_t get_new_page, free_page_t put_new_page dst->private = NULL; if (!folio_trylock(src)) { - if (mode == MIGRATE_ASYNC) - goto out; - /* - * It's not safe for direct compaction to call lock_page. - * For example, during page readahead pages are added locked - * to the LRU. Later, when the IO completes the pages are - * marked uptodate and unlocked. However, the queueing - * could be merging multiple pages for one bio (e.g. - * mpage_readahead). If an allocation happens for the - * second or third page, the process can end up locking - * the same page twice and deadlocking. Rather than - * trying to be clever about what pages can be locked, - * avoid the use of lock_page for direct compaction - * altogether. + * While there are some modes we could be running in where we + * could block here waiting for the lock (specifically + * modes other than MIGRATE_ASYNC and when we're not in + * direct compaction), it's not worth the wait. Instead of + * waiting, we'll bail. This will let the caller try to + * migrate some other pages that aren't contended. */ - if (current->flags & PF_MEMALLOC) - goto out; - - folio_lock(src); + goto out; } locked = true; -- 2.40.0.634.g4ca3ef3211-goog