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 5D30DC3DA7F for ; Tue, 6 Aug 2024 02:07:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DBB806B007B; Mon, 5 Aug 2024 22:07:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D448C6B0082; Mon, 5 Aug 2024 22:07:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BBDD86B0083; Mon, 5 Aug 2024 22:07:56 -0400 (EDT) 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 9BA1C6B007B for ; Mon, 5 Aug 2024 22:07:56 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 1865A41EED for ; Tue, 6 Aug 2024 02:07:56 +0000 (UTC) X-FDA: 82420184952.09.66AB0B4 Received: from mail-vk1-f180.google.com (mail-vk1-f180.google.com [209.85.221.180]) by imf15.hostedemail.com (Postfix) with ESMTP id 588D5A000F for ; Tue, 6 Aug 2024 02:07:54 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=muYxcbae; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.180 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722910023; a=rsa-sha256; cv=none; b=Oqpdr04t32A09jEjbNfBcG0qeFRPJjwnAFP+2LZ1aUXCweSUigwBSDjnSPS8nv7k8+Jw5h E7GVHcuZRWrWXrv189knVFt6R+1Uu4f8u2/cBMjkHlpP0qG9eXLT2slWW3TzCIGZwa4gdo MFnZVOSDIOR90fOcaLKGeSGZ+OJQ0Go= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=muYxcbae; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.180 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722910023; 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=LARZc07LADq71T7/7gjiP1ItyFSC8ak4cgcFWtYqKus=; b=bUe4agjBCFIO+zL0l6T4dKRTSiff36wFip+jg3NYqLg0Loy4DQ/9CFkUBcVHjwfx7P6pJL BlrM1Vkaaj7irwvK/zu8p/4KNvnvvqX0OVi4ruGm1/i9grLnlcNCM+uxj03RdhWMX8mWm1 CcwvAw5Y5gOsFhqdfk1RfhdJXWoDM8s= Received: by mail-vk1-f180.google.com with SMTP id 71dfb90a1353d-4f6c136a947so13422e0c.1 for ; Mon, 05 Aug 2024 19:07:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722910073; x=1723514873; 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=LARZc07LADq71T7/7gjiP1ItyFSC8ak4cgcFWtYqKus=; b=muYxcbaexkJ0HD29jyw5N8yvGr8f90VqdR7k/TZ2LwPLxnBLKFYIHSHcAuLgdGT6U1 QlPcJy7WnE4va9vZgeE0uX+NGN2PijMUz8Vko2wcUki62eT+3+vhkGf67bLVIteigbfG Z4AL4SxOxdrzNktadifqb+S7mynx68Yfbq+PPI5gz21G97930e7t2DuHuauDi1o2Qjy0 oL28O2PHPsK+d/leTgJ6JpMgtuWrbWb0j+XoAFY5sfjEODuMoKtiRIY4L04tK2S4qLtx 4LSbt23oihQApVvUnhrV/7zJo5S3tMmmMP3ZhkZTpV6g/trgjLwW6sA0y4HpKsAgnShn Jw4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722910073; x=1723514873; 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=LARZc07LADq71T7/7gjiP1ItyFSC8ak4cgcFWtYqKus=; b=D51eKPk2js/bvXwTImS+BjQvTRlXEqcWdSjs0RTOzOwzDFi5EDX6AOxG+pujiRSdDk uObVreTOg0VaABNbnJqd+KWQm8w6ANUPmaovXLhE0RuoFMK22jmrPkXHsKz6mexp/Ej2 NOxKohcwh2bf3SG2sInHALjP/hXBmcg86uUnfzGk4IDvTtoE0vBZR1sMZJcn43iC2NEH 9IdNWAvbUue0fZICDU50daSPMZeN/y9sPxnDUjwjGf0tZHoDc72ZS8kszmDmULyVeEYW vpQgwGjdTDikN8ABt2j1DcdlBhBkBu1LCp+M59VTbq2Z9bDfW3A6CPqmnkPwfa1Oo8Yg bJKQ== X-Forwarded-Encrypted: i=1; AJvYcCVbQqCGyRxc8a8Ha9jiI+v2KdBc0pUkMo+4qR0rgjxAMTSfSht6yd8IrSHuIxNKZHMye8CS3HdGB+03IhG9YNA0vRU= X-Gm-Message-State: AOJu0Yw8F1EGxQx+gHa86p1YcEyGYL87bG2f8oWIvs1CKbOLINjrHfv6 Z/CZzjhutcRqi2FnkPomnRyZatSLfAWkp8w1iWUe+E73cWzXZTknwWHILPSZprmQKCLco1VR05x q3qMyVC35YZXSPSfSEqgg8ZOR5zM= X-Google-Smtp-Source: AGHT+IFIyuATzo+ZeR3WGkUmX/hHU0lijXzN/fAJpO+nJAsrUt8SRJ56SRpxK6Zd9IuzPU8zdX28oW29AZ2TIS4xnvs= X-Received: by 2002:a05:6122:1ac2:b0:4f6:a697:d380 with SMTP id 71dfb90a1353d-4f8a000231fmr16129793e0c.10.1722910073240; Mon, 05 Aug 2024 19:07:53 -0700 (PDT) MIME-Version: 1.0 References: <20240805160754.1081-1-justinjiang@vivo.com> <3699860f-3887-4a99-b9ef-10e3f86ec3bb@vivo.com> In-Reply-To: <3699860f-3887-4a99-b9ef-10e3f86ec3bb@vivo.com> From: Barry Song <21cnbao@gmail.com> Date: Tue, 6 Aug 2024 14:07:42 +1200 Message-ID: Subject: Re: [PATCH] mm: swap: mTHP frees entries as a whole To: zhiguojiang Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Chris Li , opensource.kernel@vivo.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 588D5A000F X-Stat-Signature: wa4dzon3ctpqzf3dgpce7o4uce681i9z X-Rspam-User: X-HE-Tag: 1722910074-208376 X-HE-Meta: U2FsdGVkX1+pH+uRgFm+/gtu6llvc8tykwG+mh9fgVbeMmCvTwaD/IOE4evcGwaDMKp0Z0XoLJtR+N0phsgTHtj0VdYFk0Ktqi+gVz0UuACTMSVMaOAftYPdle2yZz7X8Jj2C0rYSfk2p/CWAsPz33Pp4eObXE7JcwZBarVD9B0HTtPV2WB4WTed3ODILT2lpPnp8FY97yFpajqIgygXfq6ahXLgLycEI/iDS59wyGY4vrmkcx2A8JHm/8aQFxkEUjNbj/WHZGNSI7LfwDVXD6oCfM1R9jAWeqbC+ReDZzep5XXeUDLZDOhSxIgfyeocqp7fNoSZnWuFa24Nzb2oKc7Pun2j4oPVu4ZVfQbzzdK5xqvAunu/kk/UAb+r5S8O3KPiQmfJA3f/woHUvYL6tUbDHrJmNNeADeF9OCl8NGMckI9tBqkL5sz7D9HhQB/52peqa0N2T3TYxCloKspiVJrIs3x/qhOhOIrbyCtkAdZauISxmexI+MqcZw1dQqfZIOhjavU5H2LGivZ+H+5xqAREfeioXTD5gm8YLeF1W3RYBw7umFDCqwi5GSHkfTWHWT5/ASHMyBxt2fRrI2768H34IutrMPC5BC/Cprrah4stLyJGAF2fPdKmJXpoglrWJc6GbNaSLN9KfrbD3w2pQlrCUbQkXNwJmIDEKB/bTKDfftXw/YnoQsfE7IhO4NTyOYD/SSUh0pmMZttcGzrnmIP9GlrrevaCQAFN0UHssD4UOCjQa+V/fNq62TC5Llxeef2JJgu7vTyMDr1zxQf87jG2C/liC1tR+L+7yvVyjGNAMyiXfxmAMjS31kTJXOlz4b5mQ3+oRMVU8LEnzjHIefbX6icVcbKyqE4U+S7M3u5SFzydChND1Fo2hjNjcUWYcHwxOghlmWQCgr3IffLC0m+d/ZrnTuz7jzaHYov0oRBIhShokzYn5c1RmtNiSA2cJgxIINkfZnwPhCsDdVX 89Jd8d5U u5bEaKBMdvxEIgNQzqL+nYqOfqIsEeCe3jVCv7FqsQTktcQqN+aGqqtbkE5cW21TCjzbAjEe5dn6Dy4BGKRnmL+CJSkJKqXUV8aiRTSr6dwEpQzIlXsCY+V9JxP593DyX8qggN5Kc/Gmfp9HAvUy9w0czW6whGEWxk2QSbzm35QQlzWozcP5pjXvnJ2pvJtKfUFX/cfiWtNJYi5xtFXZXSlIrD2LSUVapvwSQJ7fonjXvYcQPEALqHHvrPFo/uPrNHPTH5Lq33Rd5wlkv8zUfv7QtJ7H4NvhRNuu/UgXryhkvy7S6RqjDbVPtvPRKj9tH/e9UOfE/tvFikE5pzShEkdHg7KmB6xiGcgeBZTg/ZGZKvKa3XExEO39ih/i3X0T2BApmUUx9pbO6mtnQXGq7AqJGUUsPI3xUBZ4Gz27lESPSuN6Yv6hjaC9tZw== 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, Aug 6, 2024 at 2:01=E2=80=AFPM zhiguojiang w= rote: > > > > =E5=9C=A8 2024/8/6 6:09, Barry Song =E5=86=99=E9=81=93: > > On Tue, Aug 6, 2024 at 4:08=E2=80=AFAM Zhiguo Jiang wrote: > >> Support mTHP's attempt to free swap entries as a whole, which can avoi= d > >> frequent swap_info locking for every individual entry in > >> swapcache_free_entries(). When the swap_map count values corresponding > >> to all contiguous entries are all zero excluding SWAP_HAS_CACHE, the > >> entries will be freed directly by skippping percpu swp_slots caches. > >> > > No, this isn't quite good. Please review the work done by Chris and Kai= rui[1]; > > they have handled it better. On a different note, I have a patch that c= an > > handle zap_pte_range() for swap entries in batches[2][3]. > I'm glad to see your optimized submission about batch freeing swap > entries for > zap_pte_range(), sorry, I didn't see it before. My this patch can be > ignored. no worries, please help test and review the formal patch I sent: https://lore.kernel.org/linux-mm/20240806012409.61962-1-21cnbao@gmail.com/ Please note that I didn't use a bitmap to avoid a large stack, and there is a real possibility of the below can occur, your patch can crash if the below is true: nr > SWAPFILE_CLUSTER - offset % SWAPFILE_CLUSTER Additionally, I quickly skip the case where swap_count(data_race(si->swap_map[start_offset]) !=3D 1) to avoid regressio= ns in cases that can't be batched. > > Thanks > Zhiguo > > > > > [1] https://lore.kernel.org/linux-mm/20240730-swap-allocator-v5-5-cb9c1= 48b9297@kernel.org/ > > [2] https://lore.kernel.org/linux-mm/20240803091118.84274-1-21cnbao@gma= il.com/ > > [3] https://lore.kernel.org/linux-mm/CAGsJ_4wPnQqKOHx6iQcwO8bQzoBXKr2qY= 2AgSxMwTQCj3-8YWw@mail.gmail.com/ > > > >> Signed-off-by: Zhiguo Jiang > >> --- > >> mm/swapfile.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++++= ++ > >> 1 file changed, 61 insertions(+) > >> > >> diff --git a/mm/swapfile.c b/mm/swapfile.c > >> index ea023fc25d08..829fb4cfb6ec > >> --- a/mm/swapfile.c > >> +++ b/mm/swapfile.c > >> @@ -1493,6 +1493,58 @@ static void swap_entry_range_free(struct swap_i= nfo_struct *p, swp_entry_t entry, > >> swap_range_free(p, offset, nr_pages); > >> } > >> > >> +/* > >> + * Free the contiguous swap entries as a whole, caller have to > >> + * ensure all entries belong to the same folio. > >> + */ > >> +static void swap_entry_range_check_and_free(struct swap_info_struct *= p, > >> + swp_entry_t entry, int nr, bool *any= _only_cache) > >> +{ > >> + const unsigned long start_offset =3D swp_offset(entry); > >> + const unsigned long end_offset =3D start_offset + nr; > >> + unsigned long offset; > >> + DECLARE_BITMAP(to_free, SWAPFILE_CLUSTER) =3D { 0 }; > >> + struct swap_cluster_info *ci; > >> + int i =3D 0, nr_setbits =3D 0; > >> + unsigned char count; > >> + > >> + /* > >> + * Free and check swap_map count values corresponding to all c= ontiguous > >> + * entries in the whole folio range. > >> + */ > >> + WARN_ON_ONCE(nr > SWAPFILE_CLUSTER); > >> + ci =3D lock_cluster_or_swap_info(p, start_offset); > >> + for (offset =3D start_offset; offset < end_offset; offset++, i= ++) { > >> + if (data_race(p->swap_map[offset])) { > >> + count =3D __swap_entry_free_locked(p, offset, = 1); > >> + if (!count) { > >> + bitmap_set(to_free, i, 1); > >> + nr_setbits++; > >> + } else if (count =3D=3D SWAP_HAS_CACHE) { > >> + *any_only_cache =3D true; > >> + } > >> + } else { > >> + WARN_ON_ONCE(1); > >> + } > >> + } > >> + unlock_cluster_or_swap_info(p, ci); > >> + > >> + /* > >> + * If the swap_map count values corresponding to all contiguou= s entries are > >> + * all zero excluding SWAP_HAS_CACHE, the entries will be free= d directly by > >> + * skippping percpu swp_slots caches, which can avoid frequent= swap_info > >> + * locking for every individual entry. > >> + */ > >> + if (nr > 1 && nr_setbits =3D=3D nr) { > >> + spin_lock(&p->lock); > >> + swap_entry_range_free(p, entry, nr); > >> + spin_unlock(&p->lock); > >> + } else { > >> + for_each_set_bit(i, to_free, SWAPFILE_CLUSTER) > >> + free_swap_slot(swp_entry(p->type, start_offset= + i)); > >> + } > >> +} > >> + > >> static void cluster_swap_free_nr(struct swap_info_struct *sis, > >> unsigned long offset, int nr_pages, > >> unsigned char usage) > >> @@ -1808,6 +1860,14 @@ void free_swap_and_cache_nr(swp_entry_t entry, = int nr) > >> if (WARN_ON(end_offset > si->max)) > >> goto out; > >> > >> + /* > >> + * Try to free all contiguous entries about mTHP as a whole. > >> + */ > >> + if (IS_ENABLED(CONFIG_THP_SWAP) && nr > 1) { > >> + swap_entry_range_check_and_free(si, entry, nr, &any_on= ly_cache); > >> + goto free_cache; > >> + } > >> + > >> /* > >> * First free all entries in the range. > >> */ > >> @@ -1821,6 +1881,7 @@ void free_swap_and_cache_nr(swp_entry_t entry, i= nt nr) > >> } > >> } > >> > >> +free_cache: > >> /* > >> * Short-circuit the below loop if none of the entries had th= eir > >> * reference drop to zero. > >> -- > >> 2.39.0 > >> Thanks Barry