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 B0790C47DD9 for ; Sun, 25 Feb 2024 21:14:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 026726B011C; Sun, 25 Feb 2024 16:14:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EF2856B011D; Sun, 25 Feb 2024 16:14:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D935E6B011E; Sun, 25 Feb 2024 16:14:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id C31196B011C for ; Sun, 25 Feb 2024 16:14:27 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 6BFA7A05F4 for ; Sun, 25 Feb 2024 21:14:27 +0000 (UTC) X-FDA: 81831579774.02.7139CEA Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf01.hostedemail.com (Postfix) with ESMTP id 9FD6440003 for ; Sun, 25 Feb 2024 21:14:23 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=QnYCxpBA; spf=none (imf01.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708895666; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ui+j32p0OsExvTVY7IOMabABeK0Z1XaZ00tAkljc7sU=; b=dWQpxkM/UZvbN/kcvPmKPW0lq8UEMu+SnsMus9iB4ZuxDBn/8Pvx3rAWRGNiFBSsIimbxz 93Jrvt6RGLSgXhk/hmFtv9Of3Hm9J14w0yJypi1t9/5Ao3kWCkvgDHqbuubfplCISDjcKr v0y/KM2J1JDG3WRx1blA9ufOlJoadpE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708895666; a=rsa-sha256; cv=none; b=t4Ks1R8C7Omw1SQI3elhIrIlJ8n0bGSraB31yxLAs00rqaXunWPEzwKmjx5biT/aZnrZia fAUhQp+cmtKajocyk2x7xg9jzkZ+AsrhD9QEkvaIhcK7IWm3J1CreI2o2awA3TXJBtaSsL WQTXtVWS0N/hzVA36/U/3TzjWMChs9Q= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=QnYCxpBA; spf=none (imf01.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=ui+j32p0OsExvTVY7IOMabABeK0Z1XaZ00tAkljc7sU=; b=QnYCxpBAkxK6xyG6pl4lTIwa97 jR/Iii/Dn3qQMkm7evrTbP9o7/ZJ1E2vLV2Vzc4/9qyo9/E89icovdHiZQqatGGD3UEpSuiQc42z4 Q31ZA2w8PHC268KBmNe/cfLfxBsQz+pNgPtEiT038bvPU+Lbvc88wY1VQfM7fyhJ64dAnm257p4Yp XOBtnGC6Y2J4Ej22S+C1YDDWWhgSFPeEGOlfXwmXp8OGO1YtE+fx46SUtIE9g2QwnFTE+T6qLqa/A fzqpO9m2/kB0Xgl52mo64VGV+K7od7cQaon7W6AuuWDQHtKe4lm+GgHcZz905wa6lLwdhdikHpq6h 4GqzztAg==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1reLp5-0000000F9tu-3CrF; Sun, 25 Feb 2024 21:14:11 +0000 Date: Sun, 25 Feb 2024 21:14:11 +0000 From: Matthew Wilcox To: Linus Torvalds Cc: Kent Overstreet , Luis Chamberlain , lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm , Daniel Gomez , Pankaj Raghav , Jens Axboe , Dave Chinner , Christoph Hellwig , Chris Mason , Johannes Weiner Subject: Re: [LSF/MM/BPF TOPIC] Measuring limits and enhancing buffered IO Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 9FD6440003 X-Rspam-User: X-Stat-Signature: c65gruuwnhnbx3chie7kixr5nyj8j881 X-Rspamd-Server: rspam03 X-HE-Tag: 1708895663-923818 X-HE-Meta: U2FsdGVkX19qeRPKhepRRuIt0iih3tTqy58E229edNveq6HjBwUOYJ1BYEsdm6LO3gLVM4IR3MC7uGFPdzI/KmGfqHzxL+mMUoy+XoKXNid9VYw0UvzndGHjUfG/kqZX1FOPG0tS2YD5lVA90KDRzwGeTzpywT/L2DX66s/pXNPYOnwTu81bhNg31T0jXGTYRxo1jIhL4ce7/kOLAid/uIXcmmYV1oBWozqmFcHDVUtdGQtd35YRTSlLEuArMl+ejSJZlvgqU8mvE+jo809Iw+deld6ZavdVdAkvqIGmV6RVYiw30Th24cYwlMqjm5SbsT4nKMAVHeJK/vvwZiSxARJZefmq1gBm7XPAmE90YUh+P1r7NfHt2065+NBKbrKxMPN0mMLybAg/GsIpnQZaUqJ9/qXWUQH9U/NpIW12uVZw8L0X6eqzMdUygMqwOqx/51Vh9NDNWY8b+VcDzeTBN7+5TCBzud3R9ZjS6XU69iwynR73bjMQ10VfwtT17JST6eiKBfOq6GEMVSAlNsJOk3u9AnlMYxiy89XFaNf6DyyeOAdAP/QIl6zckFDax1rPwPyXPs1Bkr8k4vs+xrxmle6ffmzPrYhdVgh8GIHA0wNJZ2F1jb97zNXmc18HLDVL25uSkuuf8u4Q6SeBsER2vp9v2GYkufETt9hdcfnQoiklpcUBrgGyDyiu30eh3ne1K7S6Uf7Vls42bbj4TaWtCvE5WQQYnK4CBDnTOno50ponemrExNNo0KJhvO9ZSoscUSarD+wyDkntAukOX1uf90O070QU05mKUm/uCguIzR4= 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 Sun, Feb 25, 2024 at 09:03:32AM -0800, Linus Torvalds wrote: > I think you've been staring at profiles too much. In instruction-level > profiles, the atomic ops stand out a lot. But that's at least partly > artificial - they are a serialization point on x86, so things get > accounted to them. So they tend to be the collection point for > everything around them in an OoO CPU. > > Yes, atomics are bad. But double buffering is worse, and only looks > good if you have some artificial benchmark that does some single-byte > hot-cache read in a loop. Not artificial; this was a real customer with a real workload. I don't know how much about it I can discuss publically, but my memory of it was a system writing a log with 64 byte entries, millions of entries per second. Occasionally the system would have to go back and look at an entry in the last few seconds worth of data (so it would still be in the page cache). This customer was quite savvy, so they actually implemented and tested the lookup-copy-lookup-again algorithm in their custom kernel, and saw a speedup from it.