From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (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 E59E3360EF5 for ; Mon, 1 Jun 2026 22:03:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780351413; cv=none; b=p6BRih4InzXxRQFZMcBRibbATU1cIkyHcmSPgzzoBEYXNqu603QhWwEzZjpJvecCuCQ0UMFQQJE50L9EhFnBqc8T70bRaKbmPOCEd5XRc3vRMVh5sI3BeZXW1B4ksKJ1n3Yx7GQDYS/jWLWeWyfV8ZuWcFr3IX1LJGtYUN5kZA0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780351413; c=relaxed/simple; bh=83lncxcpot/Afd5XIwcskqRkvp1vv5KnwdPLSaz2B1c=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=dqsP/rRzN2OlGGTDHCwwZJTqFBZfJehYkxeHEq3qC0rQW0zos30Jm/IoXdoieE9gDyk8rvX4kdnGSG42LIqNzfiqEIjkE4zEjyVzKpCvQLTG7O6OHw7+NIt5QfvGlJd6C/cId89pUfnJK6nmn1x3APn+33JyFWdDV6qwnfPeNik= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=BH7EXDYi; arc=none smtp.client-ip=209.85.128.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BH7EXDYi" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4909e3fa4b2so35368655e9.0 for ; Mon, 01 Jun 2026 15:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780351410; x=1780956210; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=ldPi0/vo1HBN6vtwxFpHQongTWGF3H0cNZG5BgrmAm8=; b=BH7EXDYi7ssUFijv/vTYa5M29cIxuI021KvN6+hxmv87oT5Yy7769qJzs2HpoY4MZu VMG4mwyC9l5pkn5alGAoQcJfgCzO+MRcopCBmXCTC77YLSnIeKXDBhmx9xZpFSrqFxQP KrWA9c4MjOEWIGlH7dBmCD/fX7Q7/MWXN6Iz2WcYnUfgeL6OjvOXXSsHyowAaqGKZYVQ iRjTxwxjs8oMgqLj2y8usMdJoVazEB0r4ZUu5jsLzS/VH3ZP4u6MGbys2IsG6e+qkkfU 4zX0q9mdpas6JB+8I4Y9/cCis7OwGvnDX3bEOnfLQnSwTrYKXUO2Fy4rsxPseXjeVWY/ 6ssA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780351410; x=1780956210; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=ldPi0/vo1HBN6vtwxFpHQongTWGF3H0cNZG5BgrmAm8=; b=ZkoNGQxM+Vt2yCgbpw21vmGNqPz4fofF58Y42DCHH6RSjXN0bIigK7Q8ui4bh6b0Ji 4lgMrNAJ5Raoki5QndYK0soUMBPcXv1wUcujXQvCvS6P07ndm4u1ti7CpsSuTl3pKFqJ J3LGbiegO8UIIunVst+z+4hj/Rn07ZT5E8cNH6ox0F1sDCPJrIm4ZaZeTB6QGBoOCKa2 13vhcB0gb8KenGGPPQIh+8BZ6ZyKAPlFwCxed/yaJHiKxUrWB9diJcMtl5SLgJzHPOMw ZY+hxtIozzsngI6gMG7562zXyfMcYtYqnZQ6N1eyCn+prC7htXXVRYqxO3sKyk08GiSA Dgww== X-Forwarded-Encrypted: i=1; AFNElJ+fzq0BnUIbuPipS1CwQPqOzt4rsyp9QaIYi0XFEA+/1frfK/1a5hMOfvZkf0pMi97Gu2UYcyOzozcEIbw=@vger.kernel.org X-Gm-Message-State: AOJu0Yw5GMlVRGOOeZeYP4P46BrSzwasvG1F1c/rpCkbDuyPnnv94zTO JI43rHjPlcf1cGe1Mz7uCKMbwjLfL82AEji13OCqmO4w9VDPruz7ssTR X-Gm-Gg: Acq92OG+gqZsGt8Zad0R2d5H/tyHqDxIo2BbgActu++0HYeTU+9Vaus9e7mCNptIrqe 1MQZKlNzdAxiNbOxXMxnlBGlL6vzPhRJ3a17QOq0U2vpuOvzsO4/bQi8z5BQled2PP0bKzza2Ac R18O9vhAjVoNP7TdffBEIuTyx6YQ5Gu4vUjZoaVQD9Dmx/8Y8ErpM7zHj0IQzyWTaHYmVI2/a8I FAoxFQ5pGMuybhtYjkdNKqol6GRCRQcbl8IHcKKWRj0569WWe4L6gZH8b3yul3x/WNVKSWF13Sx O4dh0jkGigw0EZUyup8IcRo+w1zuwqXpWrUzJPDyD1U9NguH6NgnM943L4Mor+ii317p1YNvesv /dedwc9QBL1//1D9FdYwgw6USDicnje7g7LgwA3nzRsrgT1PkXc20+u3uMC6cy5ei5uvJ2HA/xW rDLgpSsxSREyuDyjld9/SHfpmnLH+zjz94rtaqdsi66vFNp4S4dOAr8KHEC0hdsEfzyWdRaKA= X-Received: by 2002:a05:600c:8b35:b0:490:5380:f2cb with SMTP id 5b1f17b1804b1-490b0702af7mr28495355e9.0.1780351410286; Mon, 01 Jun 2026 15:03:30 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4909c09ac4bsm84800275e9.3.2026.06.01.15.03.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Jun 2026 15:03:29 -0700 (PDT) Date: Mon, 1 Jun 2026 23:03:26 +0100 From: David Laight To: Mateusz Guzik Cc: Matthew Wilcox , Chi Zhiling , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Jan Kara , Andrew Morton , Hugh Dickins , Baolin Wang , Chi Zhiling Subject: Re: [PATCH v2 3/5] mm/shmem: introduce copy_zero_to_iter() for large zeroing Message-ID: <20260601230326.09981e44@pumpkin> In-Reply-To: References: <20260601055704.167436-1-chizhiling@163.com> <20260601055704.167436-4-chizhiling@163.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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 Content-Transfer-Encoding: 7bit On Mon, 1 Jun 2026 17:02:01 +0200 Mateusz Guzik wrote: > On Mon, Jun 01, 2026 at 02:22:04PM +0100, Matthew Wilcox wrote: > > On Mon, Jun 01, 2026 at 01:57:02PM +0800, Chi Zhiling wrote: > > > Currently, holes larger than PAGE_SIZE cannot be handled because > > > ZERO_PAGE is limited to a single page. Add copy_zero_to_iter() as a > > > wrapper to support copying larger zero ranges to the iterator. > > > > I think Hugh put this optimisation in the wrong place, and you're > > perpetuating that ;-) > > > > So perhaps we can start by moving this optimisation to lib/iov_iter.c? > > And then you can redo your optimisation on top of that. > > > > diff --git a/lib/iov_iter.c b/lib/iov_iter.c > > index 243662af1af7..06c54d719fcd 100644 > > --- a/lib/iov_iter.c > > +++ b/lib/iov_iter.c > > @@ -451,7 +451,23 @@ static __always_inline > > size_t zero_to_user_iter(void __user *iter_to, size_t progress, > > size_t len, void *priv, void *priv2) > > { > > - return clear_user(iter_to, len); > > + /* > > + * it is noticeably faster to copy the zero page instead of > > + * calling clear_user(). Shame. > > + */ > > > This is a rather suspicious claim. If clear_user is indeed so terrible > that it is faster to copy, the routine needs to get unfucked instead of > the problem being worked around. > > I can't speak for arm64 or other non-amd64 archs, maybe these are > horrendeously broken. > > On amd64 some archeology shows the following: > 1. 0db7058e8e23e6bb ("x86/clear_user: Make it faster") > > 2022 vintage, replaces thoroughly terrible 8-byte per-iteration write > with rep stos usage > > 2. 8c9b6a88b7e2f33c ("x86: improve on the non-rep 'clear_user' function") > > inlines rep stosb at the callsite if the CPU has FSRS, otherwise > fallsback to a new routine which does 64-byte writes per loop iteration. > > FSRS is reasonably popular by now and chances are decent the test jig > used by Chi has it. > > For a size like 4096 bytes, the 64-byte loop will be slower than rep > movsb and even rep stosq. This needs to be patched and maybe I'll get > around to doing the needful(tm) in few days (it's not hard to write, but > some care with testing is needed). I think Intel cpu from Sandy bridge onwards execute 'rep stosb' just as fast as 'rep stosq'. (I'm sure I've done the measurements for 'rep movs' and stos ought to be similar.) I suspect you get the same big gain (twice as fast) from an aligned destination (IIRC 64 bytes on later cpu). (But I doubt it is worth the cost of aligning the destination.) The source alignment (for rep movs) make no difference at all. The 'elephant in the room' is older zen cpu. Some of those are no where near as fast as you might expect. (Look at the issues using 'rep movsb' for all copies.) I can test a range of old Intel cpu, but not amd ones. -- David > > I could not be bothered to check how the workaround showed up, but it > definitely needs to be removed as opposed to being perpetuated. >