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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 29BBAC433F5 for ; Thu, 13 Jan 2022 17:03:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:In-Reply-To:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:References: List-Owner; bh=SuIMCaTK3u7s4D0Q0vi9RewWDN1HHRn2CAjEggHx/U8=; b=vrQ1YSDLoMyoBy i0LAK+P0E+hVRa3F9OgqCuLy60AqFGkR8HfvD+qjIfa7+S2x1crUgnBRqubj9ND+vbGHXcWIiHXah uHgidQUeMi/x2EW0YNCk5compiVMZ3tXCyzldxnLrvkayP8C02xyDt7Bl6Y3wlxBX2oWckLHwuCjj S2L3cOtp0+g/hRPB1i1GBzRn1P8xnybbXtzrYnjoVP0OBG1ENhuleVXH+5LbLCGKgEsPmtxnK6mwv IjD8iozN2nvwc2exr9EQbJAb7tGLT2dwu11lorSyXCFetPFJn1JOJeLHMsju09j8eyX5IstFkXCQW J2QgoWR5WmPGoqKX1xoA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n83UB-006h4E-UE; Thu, 13 Jan 2022 17:02:04 +0000 Received: from mxs2.seznam.cz ([2a02:598:2::125]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n83U8-006h3T-Tg for linux-arm-kernel@lists.infradead.org; Thu, 13 Jan 2022 17:02:02 +0000 Received: from email.seznam.cz by email-smtpc19a.ng.seznam.cz (email-smtpc19a.ng.seznam.cz [10.23.18.22]) id 46f1fd8fd2c38f1641ece76b; Thu, 13 Jan 2022 18:01:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seznam.cz; s=beta; t=1642093272; bh=btXCnBKUj5koh5OuAW6tIKoKtTa1voPx12sh0qgT0Og=; h=Received:Date:From:To:Cc:Subject:Message-ID:X-Mailer:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding:X-szn-frgn: X-szn-frgc; b=X6zByTBqlxMZ4wAONjdHGNDiGVb/qf5cjNKSKLIMfgxx8stZaemnfU6XtMCuw+xba Ds/YirnNX4kfuePlIBvHVJ6UTMUzEevWY5AF4ncHEs1QYhyaYEkcHuF0l45mFtfzoY d46BoEnsBiFw+jlFbALhfgAYN4NuWYtajzrPiuXc= Received: from PC (79.105.116.90 [79.105.116.90]) by email-relay10.ng.seznam.cz (Seznam SMTPD 1.3.136) with ESMTP; Thu, 13 Jan 2022 18:01:04 +0100 (CET) Date: Fri, 14 Jan 2022 02:00:55 +0900 From: Alexey Avramov To: mhocko@suse.com Cc: Hi-Angel@yandex.ru, Michael@michaellarabel.com, ak@linux.intel.com, akpm@linux-foundation.org, axboe@kernel.dk, catalin.marinas@arm.com, corbet@lwn.net, dave.hansen@linux.intel.com, hakavlad@inbox.lv, hannes@cmpxchg.org, hdanton@sina.com, jsbarnes@google.com, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mgorman@suse.de, page-reclaim@google.com, riel@surriel.com, torvalds@linux-foundation.org, vbabka@suse.cz, will@kernel.org, willy@infradead.org, x86@kernel.org, ying.huang@intel.com, yuzhao@google.com Subject: Re: [PATCH v6 6/9] mm: multigenerational lru: aging Message-ID: <20220114020055.0cd8697a@PC> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) In-Reply-To: MIME-Version: 1.0 X-szn-frgn: <092108c3-2aa1-4d4d-a385-941d2bc0ef66> X-szn-frgc: <0> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220113_090201_116299_6E73ED2D X-CRM114-Status: GOOD ( 12.81 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org > But the later one is more complex and a proper > handling really depends on the particular workload That is why I advocate the introduction of new tunables. > There are workloads which prefer a temporary trashing over its working > set during a peak memory demand rather than an OOM kill OK, for such cases, the OOM handles can be set to 0. It can even be the default value. > On the other side workloads that are > latency sensitive I daresay that this is the case with most workloads. An internet server that falls into thrashing is a dead server. > no simple solution can be applied to the whole There are several solutions and they can be taken into the kernel at the same time, they all work: - min_ttl_ms + MGLRU - vm.min_filelist_kbytes-like knobs - PSI-based solutions. > For the most steady trashing situations I have > seen the userspace with mlocked memory and the code can make a forward > progress and mediate the situation. I still don't see a problem in making all the kernel-space solutions in the kernel. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel