From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E27C610E1 for ; Sun, 24 Dec 2023 03:01:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="HwsqWzi0" Received: by mail-pl1-f178.google.com with SMTP id d9443c01a7336-1d3e4637853so257755ad.0 for ; Sat, 23 Dec 2023 19:01:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1703386876; x=1703991676; darn=vger.kernel.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=+F/gcQTO8i2i7S6SvYXe9DNREVuwkHj8qUrFkzAp/gM=; b=HwsqWzi0z9a3tiM4yJ6tsyRBjqmI7DzL9H0xyCxVfg5+UeK9UuBR3GSlafYBIVqeG0 gTJhT5JiK0vHkcGvcvBq1A2kRlC4B+yjCP/rH8pIGxvinWnLfnEiKSPWcJNActr8ZQmw y2QvjS8CefT3kTrcm6elC6U0oInVTk/0HFdUJntKE6uyC9mwxGRjTvDJY6qzDovbgASf eLRLYP7tbJAE3wdbEi9iWXf0D2Cs9FLte3NqjhJ9brYLfcu4miwvdc8K29CExcY7rnqW HXxFv4XNeeRkhV2FaEFL+iblZna49cecQ87CqX4sHSR1yWFyNzuppHVIn93Brke3aVq+ Li/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703386876; x=1703991676; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+F/gcQTO8i2i7S6SvYXe9DNREVuwkHj8qUrFkzAp/gM=; b=XVyFds6QlmxItYYhK5V+77LmrNkI7vDI5DiTNULfidfp82q48nVpXkfwfOGxC1odQg Yg3/wwczEZli5PFBEZpovoGxfWS1NuN+ved0MvYqt+A4Wo5NED3qvHVWmNaTtQQtUHWd wctCsFVjj08jngH27ol31GufAiAawAGYRMVKcCm7m0eLRWPTpEXdfQ8qMuHkygxB5zq+ mR752owP92Z9F1Fl2dJmzyv/66bL+TYQ6+PRZw4vC90keJwJqbheaSJ7/HhWYOILuSrT uHTyLTfo/HdraNgWyZw/HG6hLtyKi4km9Je2LoU+T/XQ+nQ8OVDZWrtl451Bv2GkHdS2 65/w== X-Gm-Message-State: AOJu0YzUydoFo+mQrvwOpP5nnft2ZnvwWQ1nPVj+VSQ1IOIA4CHos/kN bpMUlsLtDWRwo0y+T1eSVRSg/qGa10Jh X-Google-Smtp-Source: AGHT+IFQZRwyjdadHfaO6XJLQwvgeaTJ9wxak9JiLpGUOKT4elJG7t1jjZrEBz0aO3Av7+dtK8DOGw== X-Received: by 2002:a17:902:d584:b0:1d0:9fc7:6bdb with SMTP id k4-20020a170902d58400b001d09fc76bdbmr263654plh.0.1703386875783; Sat, 23 Dec 2023 19:01:15 -0800 (PST) Received: from [2620:0:1008:15:ed14:1d0f:e856:8a58] ([2620:0:1008:15:ed14:1d0f:e856:8a58]) by smtp.gmail.com with ESMTPSA id gx10-20020a056a001e0a00b006d9a6a9992dsm1576151pfb.123.2023.12.23.19.01.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 23 Dec 2023 19:01:15 -0800 (PST) Date: Sat, 23 Dec 2023 19:01:14 -0800 (PST) From: David Rientjes To: Chris Li cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Wei Xu , Yu Zhao , Greg Thelen , Chun-Tse Shao , Suren Baghdasaryan , Yosry Ahmed , Brain Geffon , Minchan Kim , Michal Hocko , Mel Gorman , Huang Ying , Nhat Pham , Johannes Weiner , Kairui Song , Zhongkun He , Kemeng Shi , Barry Song , Hugh Dickins Subject: Re: [PATCH] mm: swap: async free swap slot cache entries In-Reply-To: Message-ID: <0a052cb1-a5c5-4bee-5bd5-fd5569765012@google.com> References: <20231221-async-free-v1-1-94b277992cb0@kernel.org> <20231222115208.ab4d2aeacdafa4158b14e532@linux-foundation.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Sat, 23 Dec 2023, Chris Li wrote: > > How do you quantify the impact of the delayed swap_entry_free()? > > > > Since the free and memcg uncharge are now delayed, is there not the > > possibility that we stay under memory pressure for longer? (Assuming at > > least some users are swapping because of memory pressure.) > > > > I would assume that since the free and uncharge itself is delayed that in > > the pathological case we'd actually be swapping *more* until the async > > worker can run. > > Thanks for raising this interesting question. > > First of all, the swap_entry_free() does not impact "memory.current". > It reduces "memory.swap.current". Technically it is the swap pressure > not memory pressure that suffers the extra delay. > > Secondly, we are talking about delaying up to 64 swap entries for a > few microseconds. What guarantees that the async freeing happens within a few microseconds? > Where the swap slot cache itself delays the freeing > of the entries for an arbitrary amount of time. It is not freed until > the cache is full of 64 entries. This delay can be seconds or even > minutes. Adding a few microseconds of extra delay to existing seconds > delay really makes no difference from the swap pressure point of view. > > Chris >