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 245EDC07CA9 for ; Tue, 28 Nov 2023 22:37:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9B4948D0007; Tue, 28 Nov 2023 17:37:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 963C48D0001; Tue, 28 Nov 2023 17:37:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 804708D0007; Tue, 28 Nov 2023 17:37:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 6EE608D0001 for ; Tue, 28 Nov 2023 17:37:36 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 3556F1A03B4 for ; Tue, 28 Nov 2023 22:37:36 +0000 (UTC) X-FDA: 81508826112.07.649D65D Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) by imf12.hostedemail.com (Postfix) with ESMTP id 46C5840003 for ; Tue, 28 Nov 2023 22:37:34 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Lia00vda; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf12.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.210.178 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701211054; a=rsa-sha256; cv=none; b=VslfmGQi9APtjDpdvWyDinsxetFRT8ogYzqVQsJWHXzHlAmoG6waV+SCb+o3TcDAbGKj/a cuthKmBv9odT965km5TDJKyHrHuVubkGX0DHvCWIuKU+mGdsnOp6cf90nG/QjrIqmGphLA 0IHmMBPuuo0DBGUyw7AbVF59BnDpRVM= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Lia00vda; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf12.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.210.178 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701211054; h=from:from:sender: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=A2AafIo5QVv/abJyPMu6Yqz0MbRVWfdchikKuUJez54=; b=yCs6drcy147CrKI0wR+lnPaPWzUvKxokr1VlfUDY9KEM+buwz5Ij1JIHvmD5AYLXHHgbno R6Ij2YO8OLs3VVLpVqrVz/3LB8tKDDtyMzrP313ZkZM5y0mtWigxiXe8aOPNINWP20wGgc 65Uu1hBEne6zbxtgg+y9pgkmfrAGcio= Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-6cbe5b6ec62so4916272b3a.1 for ; Tue, 28 Nov 2023 14:37:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701211053; x=1701815853; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :from:to:cc:subject:date:message-id:reply-to; bh=A2AafIo5QVv/abJyPMu6Yqz0MbRVWfdchikKuUJez54=; b=Lia00vdaZQmFBhNCayiJNjBTDgCRnzEYtDKC71GR1YhW6zjFj+TbOcRXvJGLDMKZkb aiAIcprRNuS2L0XOUJ2V4qsjaxxEEcwPYpSdsagI7OMWVw2Uu/C/6Eo+KjyjkK7R2yMh mo7gbGTnKcKZkkjA1XWPx3GcESVv2H8/fFQWBPoYbEaV3T5RQ7tL74GDkj/ScXwFbUrx cDHf6sjGoa7lXQYln4me10oxBar8yXkCtxQzRjrQj5+0LMHdAHuxXoTg+sG/hWV0t9DT 0HJmV983EPZNEA9/KuKX+1sc2nn158iR6H2Rqj9JlV9ROZlNxwYtCwnES1GqnElhr+C0 c4RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701211053; x=1701815853; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=A2AafIo5QVv/abJyPMu6Yqz0MbRVWfdchikKuUJez54=; b=jeEyBKUAC5UX6gC3QfJxihWRyI2aj1o4TKQXwoLjYvxxFfLfFy1KPBuN9G7iZepiSf btkVNdXvI6fe7zMUku5e1GaUhRp11lxys9EibxUyNNfOvXbLd0wwzpyQjTDN/dE3eTeC jZGDUNUPk+3BzwX87m5YOHdWSXbeRIwlpxMppgJLMDzeMLGqjdjziPazfxffv61UM119 BjhyGLz57MkXDa36gKJxeeixlLdrJTGFhGUspLSU/5dIn2aQKPZUZQzLfJwbW6JXhwVu 3GSCXu4OHLQX9r/gc1/zK/fJLPnWvEuPVyG4Rn/vf+VPRnffLXIFmAg5eJUrv4d3GUte gP0Q== X-Gm-Message-State: AOJu0YxojTERJnwKbM5tgphsjC8uZ3H1CX2W0rDAm8bgN4YBAfm6GzGA C9Blj03qrsTm2LVWTyoQ8kw= X-Google-Smtp-Source: AGHT+IF5LKYG5wWLL23x6Qo8kVxiGHz9+o5SWD7Gsfczr/JsiHvaa/wL1My767AMj+AHMfmdtL1GLQ== X-Received: by 2002:a05:6a00:3989:b0:6c3:1b90:8552 with SMTP id fi9-20020a056a00398900b006c31b908552mr17819915pfb.17.1701211052890; Tue, 28 Nov 2023 14:37:32 -0800 (PST) Received: from google.com ([2620:0:1000:8411:8fd0:78d2:c604:3ac8]) by smtp.gmail.com with ESMTPSA id t20-20020aa79394000000b006cdc6b9f0ecsm263540pfe.81.2023.11.28.14.37.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Nov 2023 14:37:31 -0800 (PST) Date: Tue, 28 Nov 2023 14:37:28 -0800 From: Minchan Kim To: "Huang, Ying" Cc: Yosry Ahmed , Chris Li , Michal Hocko , Liu Shixin , Yu Zhao , Andrew Morton , Sachin Sant , Johannes Weiner , Kefeng Wang , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v10] mm: vmscan: try to reclaim swapcache pages if no swap space Message-ID: References: <87msv58068.fsf@yhuang6-desk2.ccr.corp.intel.com> <87h6l77wl5.fsf@yhuang6-desk2.ccr.corp.intel.com> <87bkbf7gz6.fsf@yhuang6-desk2.ccr.corp.intel.com> <87msuy5zuv.fsf@yhuang6-desk2.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87msuy5zuv.fsf@yhuang6-desk2.ccr.corp.intel.com> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 46C5840003 X-Stat-Signature: hd8s1yqaxmxefoejgeqzytb8ifbzw584 X-HE-Tag: 1701211054-155467 X-HE-Meta: U2FsdGVkX1+UlSvJRJfVssljE8cW86n6xgDda9RyR2xMnalGxBKDcfrhHMzZrtW/RY8OsBF28kdRzaxU7szXzq+zJvdvUExMV79GrWo/4IBROa1vejun4RhpZFkKAcjJ99d58zeV8/rkBFgcUh71WFuTDWKz8tWDDJykZGpcWuaMhLWoUVfONgHbdfqkKlDvjBSAamdqxQjpq2x36l2ucH5ZKYAlOtfX+hzAnQzgBZVtfKTv+j6n982hSsFfugLnG/UcMdliX4SKZu9bNoiKJvatetkawbNj2RNLDUv73t86NHlFcq7ydL9uUK+JapWFMYGmiKyu1PMMBofImvhIY63B1Xrva3ASMX6SK/zy6QjE1KOxh6aO/TJAz3TjMmwiA7nuTZ2MYRw6Sil4m2mel9TPQ9WdCbogcypQmn3bCn8GmRb/y3pMZyrKKXUJBCtxWqLFOFOVCKh6AG/obYmRxMEn+MjRm16VdZeS7o4BBtSpTAUwr5n6RsnaoNctb3DPuSfDw4w6rchqeuDAtYrCpMHihOQ8GUTOluwthRAS0AUfco8Cjdj9kZ2CyYIYSGE0pAEnWL9E7cmZ5/VRs/b9DV73nTjBXW0I4bzGRUEVI6kDkyC7a/EKcv7yFBuiiHqVaZyuc+aPCohfLhYltgiKFa2LHbC2Mf0kcd51LUHX1W1XYMSRDwV5/LbJGIb+1syJfbjh1gI2KzMZNK6cLXxyG0tPDVtzMSCskqAfWvqeK8+LnmWPqryR+wxMvJ3cvX4dBbGiXqY0YsFpzwKAnCnv6loaLfOlmscyymAOYJs6VJ+hoF6Nq/6Ja73hIFTKgykdUTR+MjKR2wxPIxUCFqMuBhjhbEnuagZYgMvF8797hzdmtmVLj83RI9v4fEl99WLrKKC1o1CNekDcWL7f6yqoHBtKX68duecOKUWoB4+POxqtQKBVHr+m4+yC0rSXtz3xv9TAXw48eyYweh+MOsV qsnTR43j dQOztR5bKbLZiwSOzjkYZ3kXTtmcdnd7sRy4mZVzqk8TXUv49LlOqGi4GGI+y93T/vCdUI+zQGi9B+52kOgh9Eh96UwnLuqPl8AGK0gAOsFKQyeCypEkYP8ZIo3Hcqv5ckavNOFMaH33OlyaO5s0GYMUlaUN7Rb9J5L4EC/cAesXeuUASy4Q/w2MeVFMNbn/wsDfj+aUPvJC2hKTsMxsldnIEU4iJgrnPaaBvT9fkPO2jMMJF73jFiswVevJkrzcI5dh//X/7riAoPRs44xkc5MFl+/vd2K+BFuP3HSs0E+kEWkn26mmggYiD+/rnLdnm4yCC8h3kgbVnSuOHebpF/moaCmd3UocFIqTOqGcTrIAr4162Mf9COBYH5trR9kjO8skTGpOoUnB7uIPKA1E0kqABF0JS1ZIQbs1wKyCgOSNAbwJMuoHmwDx5Loj4C7MPD/+AohYMPMJ1MokrDVW2mmuZS/yLiuWuOcoYX1cHsaXCuuvUHZH4sMmLV0xA0AIOIkHCULld/RmCDlV3FCLGZmAkt7vFlJNuJcltRnU+g7TQUAisappOFiCvd6uD3skROO/I7Kbz0wLVBXnoIkejX0vZ4OTWmdMyG2WiWpUXgS9rXERXhgzWtMNUQuVPNwBdSzCiIz/TiIqJpWxAF6jlKxmqx66aZSU+CSXoShK1hy2G5Rq3TK4mj5AT5jM06L5vXBVp/iNIpTC3IDk= 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 Tue, Nov 28, 2023 at 11:19:20AM +0800, Huang, Ying wrote: > Yosry Ahmed writes: > > > On Mon, Nov 27, 2023 at 1:32 PM Minchan Kim wrote: > >> > >> On Mon, Nov 27, 2023 at 12:22:59AM -0800, Chris Li wrote: > >> > On Mon, Nov 27, 2023 at 12:14 AM Huang, Ying wrote: > >> > > > I agree with Ying that anonymous pages typically have different page > >> > > > access patterns than file pages, so we might want to treat them > >> > > > differently to reclaim them effectively. > >> > > > One random idea: > >> > > > How about we put the anonymous page in a swap cache in a different LRU > >> > > > than the rest of the anonymous pages. Then shrinking against those > >> > > > pages in the swap cache would be more effective.Instead of having > >> > > > [anon, file] LRU, now we have [anon not in swap cache, anon in swap > >> > > > cache, file] LRU > >> > > > >> > > I don't think that it is necessary. The patch is only for a special use > >> > > case. Where the swap device is used up while some pages are in swap > >> > > cache. The patch will kill performance, but it is used to avoid OOM > >> > > only, not to improve performance. Per my understanding, we will not use > >> > > up swap device space in most cases. This may be true for ZRAM, but will > >> > > we keep pages in swap cache for long when we use ZRAM? > >> > > >> > I ask the question regarding how many pages can be freed by this patch > >> > in this email thread as well, but haven't got the answer from the > >> > author yet. That is one important aspect to evaluate how valuable is > >> > that patch. > >> > >> Exactly. Since swap cache has different life time with page cache, they > >> would be usually dropped when pages are unmapped(unless they are shared > >> with others but anon is usually exclusive private) so I wonder how much > >> memory we can save. > > > > I think the point of this patch is not saving memory, but rather > > avoiding an OOM condition that will happen if we have no swap space > > left, but some pages left in the swap cache. Of course, the OOM > > avoidance will come at the cost of extra work in reclaim to swap those > > pages out. > > > > The only case where I think this might be harmful is if there's plenty > > of pages to reclaim on the file LRU, and instead we opt to chase down > > the few swap cache pages. So perhaps we can add a check to only set > > sc->swapcache_only if the number of pages in the swap cache is more > > than the number of pages on the file LRU or similar? Just make sure we > > don't chase the swapcache pages down if there's plenty to scan on the > > file LRU? > > The swap cache pages can be divided to 3 groups. > > - group 1: pages have been written out, at the tail of inactive LRU, but > not reclaimed yet. > > - group 2: pages have been written out, but were failed to be reclaimed > (e.g., were accessed before reclaiming) > > - group 3: pages have been swapped in, but were kept in swap cache. The > pages may be in active LRU. > > The main target of the original patch should be group 1. And the pages > may be cheaper to reclaim than file pages. Yeah, that's common for asynchronous swap devices and that's popular. Then, How about freeing those memory as soon as the writeback is done instead of keep adding more tricks to solve the issue? https://lkml.kernel.org/linux-mm/1368411048-3753-1-git-send-email-minchan@kernel.org/ I remember it's under softIRQ context so there were some issues to change locking rules for memcg and swap. And there was some concern to increase softirq latency due to page freeing but both were not the main obstacle to be fixed. > > Group 2 are hard to be reclaimed if swap_count() isn't 0. "were accessed before reclaiming" would be rare. > > Group 3 should be reclaimed in theory, but the overhead may be high. > And we may need to reclaim the swap entries instead of pages if the pages > are hot. But we can start to reclaim the swap entries before the swap > space is run out. I thought the swap-in path will reclaim the swap slots once it detects swapspace wasn't enough(e.g., vm_swap_full or mem_cgroup_swap-full)? > > So, if we can count group 1, we may use that as indicator to scan anon > pages. And we may add code to reclaim group 3 earlier.