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 7D0B6C05027 for ; Thu, 2 Feb 2023 18:27:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C41A56B0072; Thu, 2 Feb 2023 13:27:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BCA016B0073; Thu, 2 Feb 2023 13:27:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A6A0D6B0074; Thu, 2 Feb 2023 13:27:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 902436B0072 for ; Thu, 2 Feb 2023 13:27:31 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 4F9E9120932 for ; Thu, 2 Feb 2023 18:27:31 +0000 (UTC) X-FDA: 80423184702.28.19B6192 Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com [209.85.219.182]) by imf07.hostedemail.com (Postfix) with ESMTP id 88AD540014 for ; Thu, 2 Feb 2023 18:27:28 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=kBmTcd8o; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of shakeelb@google.com designates 209.85.219.182 as permitted sender) smtp.mailfrom=shakeelb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675362448; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=pjDgomZIywp7e6CSQ2Vxhlha4qbmdscu2vXAz8lYKTA=; b=uhNdy0H8uCo/ilHpLw52LTL4igGLENJjgV/4av94ZIRDTAKS9SD1JPMwwm4/dTCeTxy5Zm Db7RSliuZleB0/lEgbUliNuWQVARMSMFUj6G/WTS6XR5ukpGOBCRnF1ztKFPuSBPFkr3IU 7nspA/OKXl0yYPW4sdqrrAKEaYX5IIw= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=kBmTcd8o; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of shakeelb@google.com designates 209.85.219.182 as permitted sender) smtp.mailfrom=shakeelb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675362448; a=rsa-sha256; cv=none; b=M5J52NdFlspqwFdw+enJ9s//j7hPQAfxQjXBAsYlQfv50uULYkVqIhRR+YjuZk5EbPFKro XBek8DWm+7K6OPy6fgKVctWekjWFCNRVxVlEwK/QW+HGw2HdeBO14KUZBEVBHEgNuaQQlT ZHGrpzFdryl8TP/qcuc2pThJtT95mqI= Received: by mail-yb1-f182.google.com with SMTP id 129so3402418ybb.0 for ; Thu, 02 Feb 2023 10:27:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=pjDgomZIywp7e6CSQ2Vxhlha4qbmdscu2vXAz8lYKTA=; b=kBmTcd8o1o1lVFPHTCamTTlrH1XgzC6/Lm8P51JWY63/kZfoZBGAxxVnl7fM/nB325 IxzufFGHbol1OmmWvAiywYQ+Fy1QBuXWrZwLlN1qQ9z7IxRm32vgeSaVK119yYYHHSqD TChuw3JNRefL7J6YRb8mNWhTuYUswyasUCYKhDwn09eouJjPhcFUN0BUZQV2duIsSs/+ fYf40hTpoQqE25xwSQupwMUMWfX4lPXh6vDLt1AW/718EH/LIEdCdGVP5lsYKzieKxN9 ASVVs6xST3c54vncqQG/W+tR2N8h6Dj53Uzd1jGD1vjnvlqo65wzLMf6u8eqeM5CeZar VTgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=pjDgomZIywp7e6CSQ2Vxhlha4qbmdscu2vXAz8lYKTA=; b=QzkNOAFuCcTyapyk0M+Z6qP6uLpQVk4X1pXeQSi6fLbD7l4vosXSQqWQnWQFdHVVkf AAU28vwPAU6NY35/vROddy+5xdqbjZvQerNbg62imvraJVZroMnosV1ci9ajt9sFUhW2 cyykemP6Pr39ZXXxQdy6r6NnL2/fyXy2zN3+P0jmXS6xsEjyk96klgYEuqvRa74F0B27 pcnZzdNrXRnokHwYbrFtyUKX+wQqLX6ZlZH0xeRBkncoW1JgIupDrrz9hegvAqG+VKMV TbEeTAXDIg97zoru2QB0PFM6AtkygXuiiuJigyHXys4gNIRXNgso2yvAYkkz+vGo0Ypr cZ4w== X-Gm-Message-State: AO0yUKUDy3xj5j1KEOs/ivzEOIW5STYLpdZlzIwes3ZKcytWEcFn1igS lzgIRVwK83ePajO2Vrbzodm8gSFASyAhYRNOYOTUAg== X-Google-Smtp-Source: AK7set/Hnx6lJHCqj73tIGeDFi1YJ8GWSUaM63IsKEvF4eFWlNkSiVnp42bGA0R4p4mwFHS+jEPi0S9fHu83FSWWH1Y= X-Received: by 2002:a25:ada8:0:b0:836:46e3:fa42 with SMTP id z40-20020a25ada8000000b0083646e3fa42mr593380ybi.228.1675362447371; Thu, 02 Feb 2023 10:27:27 -0800 (PST) MIME-Version: 1.0 References: <20230202155626.1829121-1-hannes@cmpxchg.org> In-Reply-To: <20230202155626.1829121-1-hannes@cmpxchg.org> From: Shakeel Butt Date: Thu, 2 Feb 2023 10:27:16 -0800 Message-ID: Subject: Re: [RFC PATCH] mm: memcontrol: don't account swap failures not due to cgroup limits To: Johannes Weiner Cc: Michal Hocko , Roman Gushchin , Tejun Heo , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Christian Brauner Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 88AD540014 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: apei1fpg8cyu5c317zjibmbn5pezdzui X-HE-Tag: 1675362448-21961 X-HE-Meta: U2FsdGVkX19ebW2YRpMfYEEeAgYo7xvV+ub/K+a7dEfMWBxcokHYD4nQvIxg0Lw8ITC4yyZX6dx2CJldXkiJoLqpCAAKi241tTGm6ACIJK7g0TqjrIVUQnd1GYgx/v1/DejkiEqM6ULPYQ5NsMzTZFq5QvpKBc6mhYXqkdhCUpbJTV/qDWaz0/QZ4pXKj5GCz/tTMqHU6+VRjPU8Hrr7u2yclNBGxV5xisYepv03yEXI8DqILAmsuENtpJgoQic2gg46OecfQRx8hyqRSyuy2dVQUoOIqsGfwhOiAjGAmnMeSFVXvion+nfzPaMfGEHPsjc8DTp7lhNwEDykbk5x+PV+cNGpaBHX/9EL1gFWg2fVPODdWYgIpDRR3P+ydLdXtEZdi0Xpg0Irq7fBPPKFs5X3daw2zAv0CRwbcaiYF8AYeGyJOw5CKAUkaVC60zQzkil2sKkHC4RlXiFzTdZKg2jy+CZcFHYv+O/cZLDKX8aRVyQkcqJ1ljLABO9ZqBdMjZi/32pC1n3zIHQjWEc7qPuCXxByD37xmxpg+0lKJYXDFuAekrrFMSlwo860bgq1g2G0qF2dC3I2pfwW4eVMPvgLpoF+Dw2vCdoxCf26J9NpH3AEWtgcmCuSMUmBU23uC2b5CFiMVNhuoTGXLNCzrTLqoZu6pB60TBiixBfre1RBCoX1ImAWN8xnXcJfmbFSSG9qIDJ1JNDj/NisNUHLuPRAJeXjfDZrketV/yVbMnIeJ7hRgAE8fApeiRkCL2d1MFI7DKI9KwveyZVj5YQ+3IFvtlUjPovfQlnpwUocnZKox+UYnDh7xvauUcWNq7vLkiXaDKJxpbS5veblQMRrbJUyvGToiJQTD+N6pBaGLsTnSDuWyHxggnHbZlfPDe0k/yO0jr+nxMet+jhivYujSTwaEAl0RZef78TKhKR8dxIzOcvU25+NnMfEd72TvgvUYjGTNuS8LepiHlcVBAD ZzXEO4MH UcKIsGq0vUhgEM66+euPIFB63rkq+nDJsHdoChK4TP/SmZ3ycAaKepiqKwTExGWGX0/6L+f3dvog0oTm9vs/snT0jMWZF1jesH0QRu8b29OjSTH+H0FEnKtSOOkGSPuoKkA3hW1ZK0h/kLx1FTM1V+eoA0L7O3tyTN8L3CjbTbUIyK2+tTGm5FJ5i2izTgtlHior029nFhn5Idhl/nbDxSPKLWBV4+QOZiSIrXB6n0s9HMQffF9nypVBcElgbuCkNjOt6BfdEL6rYk/71HQgdxBy6QNW8R71B+w0Jo7xI4Sc9J6ruzY7hP0+48EmMuv6p1SZl+ObIOY4tNwPNhprMAjoVJyKEyUVRuyg4JbCzq4sjZbNj+8+Stcuf+CWk1nZCYdni 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: On Thu, Feb 2, 2023 at 7:56 AM Johannes Weiner wrote: > > Christian reports the following situation in a cgroup that doesn't > have memory.swap.max configured: > > $ cat memory.swap.events > high 0 > max 0 > fail 6218 > > Upon closer examination, this is an ARM64 machine that doesn't support > swapping out THPs. In that case, the first get_swap_page() fails, and > the kernel falls back to splitting the THP and swapping the 4k > constituents one by one. /proc/vmstat confirms this with a high rate > of thp_swpout_fallback events. > > While the behavior can ultimately be explained, it's unexpected and > confusing. I see three choices how to address this: > > a) Specifically exlude THP fallbacks from being counted, as the > failure is transient and the memory is ultimately swapped. > > Arguably, though, the user would like to know if their cgroup's > swap limit is causing high rates of THP splitting during swapout. > > b) Only count cgroup swap events when they are actually due to a > cgroup's own limit. Exclude failures that are due to physical swap > shortage or other system-level conditions (like !THP_SWAP). Also > count them at the level where the limit is configured, which may be > above the local cgroup that holds the page-to-be-swapped. > > This is in line with how memory.swap.high, memory.high and > memory.max events are counted. > > However, it's a change in documented behavior. > > c) Leave it as is. The documentation says system-level events are > counted, so stick to that. > > This is the conservative option, but isn't very user friendly. > Cgroup events are usually due to a local control choice made by the > user. Mixing in events that are beyond the user's control makes it > difficult to id root causes and configure the system properly. > > Implement option b). I prefer option b too. > > Reported-by: Christian Brauner > Signed-off-by: Johannes Weiner Acked-by: Shakeel Butt I think we should CC stable as well for early exposure.