From patchwork Thu Feb 3 21:43:39 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Aaron Tomlin X-Patchwork-Id: 12734675 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 201ADC433F5 for ; Thu, 3 Feb 2022 21:43:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5B32F6B0071; Thu, 3 Feb 2022 16:43:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 562436B0072; Thu, 3 Feb 2022 16:43:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 402FE6B0074; Thu, 3 Feb 2022 16:43:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0030.hostedemail.com [216.40.44.30]) by kanga.kvack.org (Postfix) with ESMTP id 2D77C6B0071 for ; Thu, 3 Feb 2022 16:43:46 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id E0010181F5FE8 for ; Thu, 3 Feb 2022 21:43:45 +0000 (UTC) X-FDA: 79102796010.29.D7315A4 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf30.hostedemail.com (Postfix) with ESMTP id 5FA3680004 for ; Thu, 3 Feb 2022 21:43:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1643924624; h=from:from: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; bh=V8faXE0FFtDTjH9wIDJIv18tEc+YN5rYBGQr/xW2GG0=; b=KteRyI8zaUS7C2BAOSpeONi33WGz4/lFBOSmWsZUWFdQnYFPN3h+tRoENofVcrSyVgwVKj hCxGXvBXEYhz9knoZCRx6mhisEC6KOV0Dfq+tyBtP3c/T7Gm8edG8pF3GZHCldPxYzBUYA xcv1Ca0g1g9jtO3YS6ajPu/NlrL3X+M= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-302-XpyH-6Y2NFypJBKKQEVyVw-1; Thu, 03 Feb 2022 16:43:43 -0500 X-MC-Unique: XpyH-6Y2NFypJBKKQEVyVw-1 Received: by mail-wm1-f71.google.com with SMTP id m18-20020a7bca52000000b003552c4e2550so1640669wml.0 for ; Thu, 03 Feb 2022 13:43:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=V8faXE0FFtDTjH9wIDJIv18tEc+YN5rYBGQr/xW2GG0=; b=4Q2TLDhX6DoESLwsu8G/lSfHDG3WT7JeEto5NQ06SnA45oVo/C3VoFw83XMaunKAiK zGaceO6h1zC87NNq2N4jLbvwUt462ABReLY98bxeEP+KDiaBMCc2xUA0dw09hubaskBd fS+0Cc/Xxg947LBDkf2DYQMXvL8OKqojez6XbZVFhgdDghlyU0qDMy9Bir4JWYH8xoCu gzNHLuT6IJKmG9pF/t8XESpUFHdXXdodzdgEGZUBY9ooDgRvXwK2X3o0ibYuiex9/0Il rITDdQxWKt+Ks7YHycsWFegpJRk8Q6IxXO4MtXFpxa/PbnaxjADRP7q/CbdnbmJt9WhV SF5w== X-Gm-Message-State: AOAM530SNZjq9cnIkrcInJ9g3MX2fapmKtoUU6/Dwnc7FkPJBb3SMcPz pMHGdDjg+TESZeoM96G5LDzm3XBvsMUuxjvbHw+8pRpTJzzVqXOF1NQ2OHRgOXJhYq5Fb4xlxkm RoSmlOagdVg== X-Received: by 2002:a05:600c:3d8c:: with SMTP id bi12mr11991456wmb.109.1643924620513; Thu, 03 Feb 2022 13:43:40 -0800 (PST) X-Google-Smtp-Source: ABdhPJxZptB5WgZob+g2GcdQ7EHeO6VOT34UtGxT+EbBSxHmqrqkJpMn7q8FC3oP5bQSmqatxxmpRA== X-Received: by 2002:a05:600c:3d8c:: with SMTP id bi12mr11991440wmb.109.1643924620224; Thu, 03 Feb 2022 13:43:40 -0800 (PST) Received: from localhost (cpc111743-lutn13-2-0-cust979.9-3.cable.virginm.net. [82.17.115.212]) by smtp.gmail.com with ESMTPSA id n5sm11806wmq.43.2022.02.03.13.43.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Feb 2022 13:43:39 -0800 (PST) From: Aaron Tomlin To: frederic@kernel.org Cc: tglx@linutronix.de, mingo@kernel.org, atomlin@atomlin.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [RFC PATCH] tick/sched: Ensure quiet_vmstat() is called when the idle tick was stopped too Date: Thu, 3 Feb 2022 21:43:39 +0000 Message-Id: <20220203214339.1889971-1-atomlin@redhat.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 5FA3680004 X-Stat-Signature: omfon8iqgnrtw5bm1j1nh8cohez65spa Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=KteRyI8z; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf30.hostedemail.com: domain of atomlin@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=atomlin@redhat.com X-Rspam-User: nil X-HE-Tag: 1643924625-786056 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 Frederic, If I understand correctly, in the context of the idle task and a nohz_full CPU, quiet_vmstat() can be called: before stopping the idle tick, entering an idle state and on exit. In particular, for the latter case, when the idle task is required to reschedule, the idle tick can remain stopped and the timer expiration time endless i.e., KTIME_MAX. Now, indeed before a nohz_full CPU enters an idle state, CPU-specific vmstat counters should be processed to ensure the respective values have been reset and folded into the zone specific vm_stat[]. That being said, it can only occur when: the idle tick was previously stopped, and reprogramming of the timer is not required. A customer provided some evidence which indicates that the idle tick was stopped; albeit, CPU-specific vmstat counters still remained populated. Thus one can only assume quiet_vmstat() was not invoked on return to the idle loop. Unfortunately, I suspect this divergence might erroneously prevent a reclaim attempt by kswapd. If the number of zone specific free pages are below their per-cpu drift value then zone_page_state_snapshot() is used to compute a more accurate view of the aforementioned statistic. Thus any task blocked on the NUMA node specific pfmemalloc_wait queue will be unable to make significant progress via direct reclaim unless it is killed after being woken up by kswapd (see throttle_direct_reclaim()). That being said, eventually reclaim should give up if the conditions are correct, no? Consider the following theoretical scenario: 1. CPU Y migrated running task A to CPU X that was in an idle state i.e. waiting for an IRQ - not polling; marked the current task on CPU X to need/or require a reschedule i.e., set TIF_NEED_RESCHED and invoked a reschedule IPI to CPU X (see sched_move_task()) 2. CPU X acknowledged the reschedule IPI from CPU Y; generic idle loop code noticed the TIF_NEED_RESCHED flag against the idle task and attempts to exit of the loop and calls the main scheduler function i.e. __schedule(). Since the idle tick was previously stopped no scheduling-clock tick would occur. So, no deferred timers would be handled 3. Post transition to kernel execution Task A running on CPU Y, indirectly released a few pages (e.g. see __free_one_page()); CPU Y's vm_stat_diff[NR_FREE_PAGES] was updated and zone specific vm_stat[] update was deferred as per the CPU-specific stat threshold 4. Task A does invoke exit(2) and the kernel does remove the task from the run-queue; the idle task was selected to execute next since there are no other runnable tasks assigned to the given CPU (see pick_next_task() and pick_next_task_idle()) 5. On return to the idle loop since the idle tick was already stopped and can remain so (see [1] below) e.g. no pending soft IRQs, no attempt is made to zero and fold CPU Y's vmstat counters since reprogramming of the scheduling-clock tick is not required/or needed (see [2]) ... do_idle { __current_set_polling() tick_nohz_idle_enter() while (!need_resched()) { local_irq_disable() ... /* No polling or broadcast event */ cpuidle_idle_call() { if (cpuidle_not_available(drv, dev)) { tick_nohz_idle_stop_tick() __tick_nohz_idle_stop_tick(this_cpu_ptr(&tick_cpu_sched)) { int cpu = smp_processor_id() if (ts->timer_expires_base) expires = ts->timer_expires else if (can_stop_idle_tick(cpu, ts)) (1) -------> expires = tick_nohz_next_event(ts, cpu) else return ts->idle_calls++ if (expires > 0LL) { tick_nohz_stop_tick(ts, cpu) { if (ts->tick_stopped && (expires == ts->next_tick)) { (2) -------> if (tick == KTIME_MAX || ts->next_tick == hrtimer_get_expires(&ts->sched_timer)) return } ... } The idea with this patch is to ensure refresh_cpu_vm_stats(false) is called on return to the idle loop when the idle tick was previously stopped. Any feedback/or testing would be appreciated. Signed-off-by: Aaron Tomlin --- kernel/time/tick-sched.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c index 17a283ce2b20..61874df064b6 100644 --- a/kernel/time/tick-sched.c +++ b/kernel/time/tick-sched.c @@ -876,6 +876,9 @@ static void tick_nohz_stop_tick(struct tick_sched *ts, int cpu) ts->do_timer_last = 0; } + /* Attempt to fold when the idle tick is stopped or not */ + quiet_vmstat(); + /* Skip reprogram of event if its not changed */ if (ts->tick_stopped && (expires == ts->next_tick)) { /* Sanity check: make sure clockevent is actually programmed */ @@ -897,7 +900,6 @@ static void tick_nohz_stop_tick(struct tick_sched *ts, int cpu) */ if (!ts->tick_stopped) { calc_load_nohz_start(); - quiet_vmstat(); ts->last_tick = hrtimer_get_expires(&ts->sched_timer); ts->tick_stopped = 1;