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 1EBD8C83F2D for ; Thu, 29 Aug 2024 14:30:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A7BDD6B0089; Thu, 29 Aug 2024 10:30:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A2AFF6B008A; Thu, 29 Aug 2024 10:30:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F2596B008C; Thu, 29 Aug 2024 10:30:27 -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 707446B0089 for ; Thu, 29 Aug 2024 10:30:27 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 1F4161607CB for ; Thu, 29 Aug 2024 14:30:27 +0000 (UTC) X-FDA: 82505518494.28.C335970 Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by imf05.hostedemail.com (Postfix) with ESMTP id C610D10002B for ; Thu, 29 Aug 2024 14:30:23 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=GU36Laks; spf=pass (imf05.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.43 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724941754; 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=or4ghMbyYGhdgKHNnt+sKMCIkofo/P/ZwT115uAVzaM=; b=pOWeZEpYfa5mf78DEpsXaRu9uYMQM5Z8y1GCYdy4zIzXBPjTOfRCzL5gddg45Z8UQ9D65z beJDi81h1THSKX0ETosrt7979xRuS4AH7VHJj1AVGdnaJSfNeNr0SaR+0q2Zn/dhfB8j4S NBLjBehX0RiDDieFolmqFXMr4h4wGjg= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=GU36Laks; spf=pass (imf05.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.43 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724941754; a=rsa-sha256; cv=none; b=n6v93VR53MFJBZteClBHIOAitj2A3xNR8TQL9FFdEcaJ52N+GHF0/tri/wj3oewCrnMOMi 4XPOnCiqJ7kXuvTwARRbp1uU6WCmmNpv78ySMRmT2+G+HrdZCXf50+9LWraWut7Vc9fzbg Qy8FFrESynGLeZr9TlOPv+LJy/cfaOc= Received: by mail-lf1-f43.google.com with SMTP id 2adb3069b0e04-533488ffaf7so1001418e87.0 for ; Thu, 29 Aug 2024 07:30:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1724941821; x=1725546621; darn=kvack.org; 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=or4ghMbyYGhdgKHNnt+sKMCIkofo/P/ZwT115uAVzaM=; b=GU36LaksI1sPzHFi3vQqZe9pPi5KiqM5d4XisXAb9YK/C1cSUGXGFRHJfavElENP7r 5flVVwwxEIVWJJdCxMWEwho0tUlzS442wiFgnrPkuaV5pW559VK+cZ0nmJh8z9z4ueEB 2xH9gu64v8i7PWgMYnw2TaaF1+jBClWNMYEA5/YTcJQaM4qbSdoLUa6Kb8vq9K+ongmu X1Dqb257XzgHvcEewhE+UQdiO6BxO66qd05G8lhcNpKEpI+wHtxPJm4X5Y/BthubmBit XW1ExknYkuSRMMkJRRejSvkbKqnxIn69CzN9NVlTWz6fpnnQXqu+Adr29oTLbWqMiJFJ cDEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724941821; x=1725546621; 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=or4ghMbyYGhdgKHNnt+sKMCIkofo/P/ZwT115uAVzaM=; b=hzUfyivJpcLQwk9NmHvTIFzk84zdMXBQ0OOg2l0ogWO3jdJOjsZU1hY+z5AC+4ezx9 CTjxAL3+6tK+0KnWaAymXAoZaQXUDTikYfg5sHg0AwWujivNzntyxco1udWSPD9Hf8QB zwWXIeWpghW4nGA7maV6E5ydHXMzAjK0jtFy91S2E/UO1d1fJ9CEcNDjoWM3OsTo4yDE oZ/g/GvvosTPL+9NNIh1nj86QnO6Fdfk86xA9QX0bp+S24vehCg8NUm8bZ/Fi/b02Tpj CCKkWK8ZwKdXHZ5GTnIKaaB7+i2cbMDqSPpR4gbdewrXCg696SlOpfOQoRhxe0UwTFxj ICFg== X-Forwarded-Encrypted: i=1; AJvYcCVSUPeZH+aNKSvvXo/RFl1UPVSEpiuAB9FEfiJ8ixg91iOT3QMx+jkcEra50C0pLdnRdBa+hpV/RQ==@kvack.org X-Gm-Message-State: AOJu0YwMp4IxbkhlblQBKeNEKeh1xtiJvyxP4MQNKSEZFT1YDeTcJSK8 LOO/fQvHE74qekJLuMPxDhyBD4vv6EqjyJIpVbRFEhYre2VFcYox3CPG6kuB17VG4qGxv5Pa5eh tB9gZNg6gNBQk1Y20cYpmzBaoaSCuE9LJngtJnQ== X-Google-Smtp-Source: AGHT+IEuD7+DRiRALY05+3l0QvDxJ+ND2HY5nhwL1zBJJKY+7V2NCB19r4XkEsnz+Z0UnfHXuYV7JUJhmzQ5ssinP9E= X-Received: by 2002:a05:6512:3b90:b0:52c:e086:7953 with SMTP id 2adb3069b0e04-5353e53fba3mr2228999e87.4.1724941821324; Thu, 29 Aug 2024 07:30:21 -0700 (PDT) MIME-Version: 1.0 References: <20240829101918.3454840-1-hezhongkun.hzk@bytedance.com> In-Reply-To: From: Zhongkun He Date: Thu, 29 Aug 2024 22:30:09 +0800 Message-ID: Subject: Re: [External] Re: [RFC PATCH 0/2] Add disable_unmap_file arg to memory.reclaim To: Michal Hocko Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, roman.gushchin@linux.dev, shakeel.butt@linux.dev, muchun.song@linux.dev, lizefan.x@bytedance.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: mr5nwki5pw73yhwb8qrtya85fzzfchzn X-Rspam-User: X-Rspamd-Queue-Id: C610D10002B X-Rspamd-Server: rspam02 X-HE-Tag: 1724941823-715342 X-HE-Meta: U2FsdGVkX1+Jw2iMBzAapFavXfTpj6iTEEmszcrqhJYQJLQIkZO5ycU0WCjMVIdsens9r7wMpdi0a6qiRUU/vu4k6Cx8Gv8k4A6iQiLvAycBvm7Q8YMMMqaesdAIk96W0fRnujqbwpyr4sK6XAnTCXZrrQqFxe/y0POsOEtjuuEan6uy6a79K2zLxCtyHsK5KSyb74GkfbdPiGftl4lfSdnutx1SxIJgdK9lcLij99M7Pb+gIFSOI9/K8aFXiOsFRgVI2kABtjIXfalcm+/Lzp3LTgmLfG16pyAY2Ziq14zlzqGGoi97R4BKmda4hHVZfUj9r2griAgqLR2etesRXaUb3EQjoqDkBCDycA97Woz+GR6mrbg9EnIlJtXlwl0UE3n2eJAsrnPCfHcz7kiuhRpcxE5ryIqjz07woY9hHrY+ZAjfWv/BVYLwVjaPNmJRYihrXEsQB4lsmBos0mcrIO77k2ibQLGt2RK48jPlHwdIQafSTFUOh3d7HORcXFCkX0XPslTWQGvy6Q+90xgRBCR132M6lsa02smRxCtYQBlF8Oj19AElZQp95A5CL0nwpdfs6dxDBaOx+SfRl/3zPoUarxmBxBDSBe0ZlOuADkB51p5i73+vDIfjaNxe0JoXAP1IxFnmNZXU7G4uxaAlcPHxUZeEBmxwzdyzqni5Ln5AI0uMrjAcNY8cybE/Yrktrw56zwBpC/nVfrROGakuvtil0lgnT7ApuJvIgqxQH4f8vCkWz+UvoQPxJ4eSUO6b9zbV8Ciulfb7nOP7e6iJgg2D8q3gBYKp5YCs3476tBvlkOwoGBO/e5oJcIMIJqD8VwR2LCNmn05Kku6/qtuHEOdweGkNfdwgVGImgKN+I2Qr5gIBO0LGN3rwL0JH/+UiPXzdQQ6cxn6bSYt6QxyXkBjVKebgoP3pTL3NcEMnJ1xJwNnx78juIi+qT4JV7KWS0j9E/W/pdGxZB+2cXRT L1J7tPjD AyuBNyE479M3VKR4aD1U1azzP2+wUDeNhUZOdBxRX5TEiFuJCFN0IOEaGlYw0XtD4CldSNliTJwBozTFyKrHGIAMyW/rtQEmg8tA1jkL8GtTK+NDpWWAA205C6XtAx4r2yJE28fHbAet20+n48KYmc68407dyC0bKjCqZCEnj5pdXMzwuGmnCx4oksmxF4OMD4RLqyyhViyPjzcMUVt0rWuXYpwR/Bw46sT70NnUhq6F6BfCX3hh0O0g9JazK05CMI8kZEJESqW1zQ1SWHBfbBneLWE00r5dg0UivSI64Hs8lLy8VCS3VzFnCUpUUZTXuO2EpmDE0GgKdUpMS6MFLNMYGkU0qWs7RGKttsWGrecDSCnsQy2L0AIjdn3kaMu9RhJsd+FtbhNdhzKpulYeSHW2Qbytl0VsiZZpbg+lSscXsSsUH7Q+gEahOyA== 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: List-Subscribe: List-Unsubscribe: On Thu, Aug 29, 2024 at 9:36=E2=80=AFPM Michal Hocko wrot= e: > > On Thu 29-08-24 21:15:50, Zhongkun He wrote: > > On Thu, Aug 29, 2024 at 7:51=E2=80=AFPM Michal Hocko = wrote: > [...] > > > Is this some artificial workload or something real world? > > > > > > > This is an artificial workload to show the detail of this case more > > easily. But we have encountered this problem on our servers. > > This is always good to mention in the changelog. If you can observe this > in real workloads it is good to get numbers from those because > artificial workloads tend to overshoot the underlying problem and we can > potentially miss the practical contributors to the problem. That sounds reasonable. I will try it. > > Seeing this my main question is whether we should focus on swappiness > behavior more than adding a very strange and very targetted reclaim > mode. After all we have a mapped memory and executables protection in > place. So in the end this is more about balance between anon vs. file > LRUs. > I have a question about the swappiness, if set the swappiness=3D0, we can = only reclaim the file pages. but we do not have an option to disable the reclaim= from file pages because there are faster storages for the swap without IO, like = zram and zswap. I wonder if we can give it a try in this direction. > > If the performance of the disk is poor, like HDD, the situation will > > become even worse. > > Doesn't that impact swapin/out as well? Or do you happen to have a > faster storage for the swap? Yes, we use ZRAM as the swap storage. > > > The delay of the task becomes more serious because reading data will > > be slower. Hot pages will thrash repeatedly between the memory and > > the disk. > > Doesn't refault stats and IO cost aspect of the reclaim when balancing > LRUs dealing with this situation already? Why it doesn't work in your > case? Have you tried to investigate that? OK, I'll try to reproduce the problem again. but IIUC, we could not reclaim pages from one side. Please see this 'commit d483a5dd009 ("mm: vmscan: limit the range of LRU type balancing")' [1] Unless this condition is met: sc->file_is_tiny =3D file + free <=3D total_high_wmark && !(sc->may_deactivate & DEACTIVATE_ANON) && anon >> sc->priority; [1]: https://lore.kernel.org/all/20200520232525.798933-15-hannes@cmpxchg.or= g/T/#u > -- > Michal Hocko > SUSE Labs