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 49397C77B7F for ; Fri, 5 May 2023 17:11:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C6A9E6B0075; Fri, 5 May 2023 13:11:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C42236B0078; Fri, 5 May 2023 13:11:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B0A3A6B007D; Fri, 5 May 2023 13:11:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from mail-qv1-f42.google.com (mail-qv1-f42.google.com [209.85.219.42]) by kanga.kvack.org (Postfix) with ESMTP id 8FAE26B0075 for ; Fri, 5 May 2023 13:11:58 -0400 (EDT) Received: by mail-qv1-f42.google.com with SMTP id 6a1803df08f44-5ed99ebe076so18217866d6.2 for ; Fri, 05 May 2023 10:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1683306717; x=1685898717; 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=t1cIC+TdX4DHh2bD3zyRHqDOXb1jCNxEJqMG31slbWU=; b=mtG7p7aWQLt/QahvISOdutO2wE2+Tq5QPZbBlpms9nnNKRRkpjknc39HoIS/UmLcXx BuZhEFPT+GhGf7b0Q1TjqvfqJJZbhB/tiTRVopeJWbLQd9Zi4mzQUvQyBV81ld6m2CNO f6X7P4oIfHifKiSnDyBN74MZOGSvZSedR1x/Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683306717; x=1685898717; 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=t1cIC+TdX4DHh2bD3zyRHqDOXb1jCNxEJqMG31slbWU=; b=NNd83d6gPDSXDCSuaXjtoQ12dVeZ7N+K5MWDA0daTuKB33qEa4SBusTy9a+SYUzpVN gxQLxCEwmycAeJmw8ISBztLUzpfQlb+bZBuU34dg4iDT22k8disEPYl6s7wkOGu5K8NV oN9qf8KDWylk8Fe7EKT3P+S68y3KYlYVvFMxAH7zQZAzfklbSPj1EhTQYlozrSltWCFO PSfEa4O5rSs5w7u4iGZv+f20ZhbfD3IKa7g0fld9BIkHx/ue0aRpjQ9YewFFkKpAojhR dRGgsosQ01qY940UMvvwGIhkzh/XBfGCtq6YX3wWzFsqq76KpH/K0CdNCbJ6fqPZARpV 0A7w== X-Gm-Message-State: AC+VfDy7GRoHDPrYZvP25Zn8KZZZ5vbR/daDrDxm56xieVsEU0kDCFEn fTwL75xwsuJHYsQ3qrtR2SZiwMurk+cPwgJnfV8= X-Google-Smtp-Source: ACHHUZ6eYzYoGg4IEr350/vCjtUVL8DJmLDONCIkdxW/lvNkFs4+/oScVRzk6VrFT97qpTBXeo9ynQ== X-Received: by 2002:a05:6214:490:b0:5f4:5af6:1304 with SMTP id pt16-20020a056214049000b005f45af61304mr3968418qvb.16.1683306716787; Fri, 05 May 2023 10:11:56 -0700 (PDT) Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com. [209.85.160.179]) by smtp.gmail.com with ESMTPSA id f12-20020a05620a068c00b0074ad4cc603dsm694936qkh.131.2023.05.05.10.11.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 May 2023 10:11:55 -0700 (PDT) Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-3ef34c49cb9so1101541cf.1 for ; Fri, 05 May 2023 10:11:55 -0700 (PDT) X-Received: by 2002:a05:622a:1ba2:b0:3f0:af20:1a37 with SMTP id bp34-20020a05622a1ba200b003f0af201a37mr294288qtb.15.1683306715201; Fri, 05 May 2023 10:11:55 -0700 (PDT) MIME-Version: 1.0 References: <20230428135414.v3.1.Ia86ccac02a303154a0b8bc60567e7a95d34c96d3@changeid> <20230430085300.3173-1-hdanton@sina.com> <20230503014500.3692-1-hdanton@sina.com> In-Reply-To: <20230503014500.3692-1-hdanton@sina.com> From: Doug Anderson Date: Fri, 5 May 2023 10:11:41 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3] migrate_pages: Avoid blocking for IO in MIGRATE_SYNC_LIGHT To: Hillf Danton Cc: Andrew Morton , Mel Gorman , Alexander Viro , Christian Brauner , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Matthew Wilcox , Yu Zhao Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Tue, May 2, 2023 at 6:45=E2=80=AFPM Hillf Danton wrot= e: > > On 2 May 2023 14:20:54 -0700 Douglas Anderson > > On Sun, Apr 30, 2023 at 1:53=3DE2=3D80=3DAFAM Hillf Danton wrote: > > > On 28 Apr 2023 13:54:38 -0700 Douglas Anderson > > > > The MIGRATE_SYNC_LIGHT mode is intended to block for things that wi= ll > > > > finish quickly but not for things that will take a long time. Exact= ly > > > > how long is too long is not well defined, but waits of tens of > > > > milliseconds is likely non-ideal. > > > > > > > > When putting a Chromebook under memory pressure (opening over 90 ta= bs > > > > on a 4GB machine) it was fairly easy to see delays waiting for some > > > > locks in the kcompactd code path of > 100 ms. While the laptop wasn= 't > > > > amazingly usable in this state, it was still limping along and this > > > > state isn't something artificial. Sometimes we simply end up with a > > > > lot of memory pressure. > > > > > > Given longer than 100ms stall, this can not be a correct fix if the > > > hardware fails to do more than ten IOs a second. > > > > > > OTOH given some pages reclaimed for compaction to make forward progre= ss > > > before kswapd wakes kcompactd up, this can not be a fix without spott= ing > > > the cause of the stall. > > > > Right that the system is in pretty bad shape when this happens and > > it's not very effective at doing IO or much of anything because it's > > under bad memory pressure. > > Based on the info in another reply [1] > > | I put some more traces in and reproduced it again. I saw something > | that looked like this: > | > | 1. balance_pgdat() called wakeup_kcompactd() with order=3D10 and tha= t > | caused us to get all the way to the end and wakeup kcompactd (there > | were previous calls to wakeup_kcompactd() that returned early). > | > | 2. kcompactd started and completed kcompactd_do_work() without block= ing. > | > | 3. kcompactd called proactive_compact_node() and there blocked for > | ~92ms in one case, ~120ms in another case, ~131ms in another case. > > I see fragmentation given order=3D10 and proactive_compact_node(). Can yo= u > specify the evidence of bad memory pressure? What type of evidence are you looking for? When I'm reproducing these problems, I'm running a test that specifically puts the system under memory pressure by opening up lots of tabs in the Chrome browser. When I start seeing these printouts, I can take a look at the system and I can see that it's pretty much constantly swapping in and swapping out. > > I guess my first thought is that, when this happens then a process > > holding the lock gets preempted and doesn't get scheduled back in for > > a while. That _should_ be possible, right? In the case where I'm > > reproducing this then all the CPUs would be super busy madly trying to > > compress / decompress zram, so it doesn't surprise me that a process > > could get context switched out for a while. > > Could switchout turn the below I/O upside down? > /* > * In "light" mode, we can wait for transient locks (eg > * inserting a page into the page table), but it's not > * worth waiting for I/O. > */ I'm not sure I understand what you're asking, sorry! -Doug