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 X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 70642C433DF for ; Wed, 14 Oct 2020 21:12:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C419221D7F for ; Wed, 14 Oct 2020 21:12:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alien8.de header.i=@alien8.de header.b="ooooy8z0" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729332AbgJNVMY (ORCPT ); Wed, 14 Oct 2020 17:12:24 -0400 Received: from mail.skyhub.de ([5.9.137.197]:39550 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726575AbgJNVMY (ORCPT ); Wed, 14 Oct 2020 17:12:24 -0400 Received: from zn.tnic (p200300ec2f0c4400e816bcc7a66b170f.dip0.t-ipconnect.de [IPv6:2003:ec:2f0c:4400:e816:bcc7:a66b:170f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 8FC491EC026E; Wed, 14 Oct 2020 23:12:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1602709942; h=from:from: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; bh=n2EEh9T4loDsc3k0fpJFPs2bQyJ8KCqgdH0vrYdkYXE=; b=ooooy8z0oo+7/MV/pYkQOKvxejlWueeJ5rMNIb/HNMCUdEQduuW3bPBVgB6pLLxFD+6Hto 3FSyicn4jrjY2TBWpUhiB8bSYHLEvoWsdnovlPKO820Mi9JUKth3F/w+NXoa5HqXzsOSoM IRbWLoNUiHIkyE40VZUh1z7JVwbwwYQ= Date: Wed, 14 Oct 2020 23:12:14 +0200 From: Borislav Petkov To: Andy Lutomirski Cc: Andy Lutomirski , Ankur Arora , LKML , Linux-MM , "Kirill A. Shutemov" , Michal Hocko , Boris Ostrovsky , Konrad Rzeszutek Wilk , Thomas Gleixner , Ingo Molnar , X86 ML , "H. Peter Anvin" , Arnd Bergmann , Andrew Morton , Ira Weiny , linux-arch Subject: Re: [PATCH 5/8] x86/clear_page: add clear_page_uncached() Message-ID: <20201014211214.GD18196@zn.tnic> References: <20201014195823.GC18196@zn.tnic> <22E29783-F1F5-43DA-B35F-D75FB247475D@amacapital.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <22E29783-F1F5-43DA-B35F-D75FB247475D@amacapital.net> Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org On Wed, Oct 14, 2020 at 02:07:30PM -0700, Andy Lutomirski wrote: > I assume it’s for a little optimization of clearing more than one > page per SFENCE. > > In any event, based on the benchmark data upthread, we only want to do > NT clears when they’re rather large, so this shouldn’t be just an > alternative. I assume this is because a page or two will fit in cache > and, for most uses that allocate zeroed pages, we prefer cache-hot > pages. When clearing 1G, on the other hand, cache-hot is impossible > and we prefer the improved bandwidth and less cache trashing of NT > clears. Yeah, use case makes sense but people won't know what to use. At the time I was experimenting with this crap, I remember Linus saying that that selection should be made based on the size of the area cleared, so users should not have to know the difference. Which perhaps is the only sane use case I see for this. > Perhaps SFENCE is so fast that this is a silly optimization, though, > and we don’t lose anything measurable by SFENCEing once per page. Yes, I'd like to see real use cases showing improvement from this, not just microbenchmarks. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette