Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp1259646iof; Tue, 7 Jun 2022 01:49:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw1qxvul4pOM9JZCS6+5QtWLm5Np8TFf3imP5i/n0PO4QuM0086s23egyYiktaHShAhF7Ve X-Received: by 2002:a05:6402:50d2:b0:431:53c8:2356 with SMTP id h18-20020a05640250d200b0043153c82356mr12529118edb.300.1654591785736; Tue, 07 Jun 2022 01:49:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654591785; cv=none; d=google.com; s=arc-20160816; b=d3fgPXET60OEnmeZCeGGbAdAETzpGr1J58c+T+jkvL3ryF9h0kLlWzu0DvM85jRyjP GY5bFyBBKdy0UeI3Ad4mJspCah2LUrDtWQsg7rAHbI13pnJ9M7Qze/K8oWrT9IXOyACk ht401+aQHq1basMZvzznbfl/iiCJuzOvFu/fPXVYClJCrWWNlan1j0j81I/PCPCgGLCI P7brqoBzgXeV5pcoupY58iHEEE9b6fZJWXhqT1QTzhqJIZ9uY9wjHXHMrUnykny7Sctj LHBFcGQuXBxF3zn+wL6qSUHIOVV1bqJYKKt7A4R0s8peC+HjFDFeFxQOiENt5PNomLQn RIhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:references:in-reply-to:subject :cc:to:from:mime-version:content-transfer-encoding:dkim-signature :dkim-signature; bh=AuSfCY0coUP9lte8BijNwvB0umn0kpaXeJN1kvIRUQw=; b=SnAERO6s6wXJywDkWwpZJCTleZW+6Q/oGrp3jWFb3OyBpdN4zUdK0zQ/EZBSgL8ZAT 9RR66EW8Ww8Y7vjR6IfOCbW5GMN63MhaAHmIJFZYXi0aLbqH0FXWqX6+WRTHOnM+SsEa +W+ZN06CMeWAVTus98mTNoz6Ad2JmaHCF6nX1pfb9Q28YWeEktOUSPNuXQZhr72rvZsS qLp8G+bpk0tIIdpRWABIVc6WZSxbgP9HfbYoLx1w2s1BKfc0/jNOKGQ6EP2i79v4YxIh PaFpGw36ZIwJEBslzvFHTbYPBLS+/vUT1w3ryr+RzR9w8sintPsTpSF+Ovfd7Hoe1Urd +IWA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=15PTDh7V; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=L9lNd+DH; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s8-20020aa7d788000000b00423de77bfdfsi17812127edq.185.2022.06.07.01.49.06; Tue, 07 Jun 2022 01:49:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=15PTDh7V; dkim=neutral (no key) header.i=@suse.de header.s=susede2_ed25519 header.b=L9lNd+DH; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235227AbiFGBDY (ORCPT + 99 others); Mon, 6 Jun 2022 21:03:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46550 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232513AbiFGBDY (ORCPT ); Mon, 6 Jun 2022 21:03:24 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B71F754BC8 for ; Mon, 6 Jun 2022 18:03:22 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 70F4F1F995; Tue, 7 Jun 2022 01:03:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1654563801; h=from:from:reply-to: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=AuSfCY0coUP9lte8BijNwvB0umn0kpaXeJN1kvIRUQw=; b=15PTDh7V5bqH0ev9PMyUJ6KI4dLMHACTQaAWGMsy6NboajTbXK+LjJVEbOz/JuzOIHXZjz QJTEp4e6gjfRqUuTwQ98ptzgq8T+0/VFy+BeEF1vNiACX4UCDsp8D8bSgEjb/H7gdOs79W bNRNQljioUkGUXFi+3g/poKKrBnKK9Q= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1654563801; h=from:from:reply-to: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=AuSfCY0coUP9lte8BijNwvB0umn0kpaXeJN1kvIRUQw=; b=L9lNd+DHU2kXKpedkq6V1wpgLoV5vqaMkI6P8Df5TtBM5SXNuTIrbNbESmZc8IYHqc6bZU 8TMod2K/rY6CizCQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 938F713A5F; Tue, 7 Jun 2022 01:03:20 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 0vxpE9ijnmIHFQAAMHmgww (envelope-from ); Tue, 07 Jun 2022 01:03:20 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 From: "NeilBrown" To: "Chuck Lever" Cc: linux-nfs@vger.kernel.org Subject: Re: [PATCH v1 2/5] SUNRPC: Optimize xdr_reserve_space() In-reply-to: <165445911199.1664.12318094116152634589.stgit@bazille.1015granger.net> References: <165445865736.1664.4497130284832282034.stgit@bazille.1015granger.net>, <165445911199.1664.12318094116152634589.stgit@bazille.1015granger.net> Date: Tue, 07 Jun 2022 11:03:16 +1000 Message-id: <165456379661.22243.4266686429763691053@noble.neil.brown.name> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Mon, 06 Jun 2022, Chuck Lever wrote: > The xdr_get_next_encode_buffer() function is called infrequently. > On a typical build/test workload, it's called about 1 time in 400 > calls to xdr_reserve_space() (measured on NFSD). > > Force the compiler to remove it from xdr_reserve_space(), which is > a hot path. This change reduces the size of xdr_reserve_space() from > 10 cache lines to 4 on my test system. Does this really help at all? Are the instructions that are executed in the common case distributed over those 10 cache line, or are they all in the first 4? I would have thought the "unlikely" in xdr_reserve_space() would have pushed all the code from xdr_get_next_encode_buffer() to the end of the function leaving the remainder in a small contiguous chunk. NeilBrown > > Signed-off-by: Chuck Lever > --- > net/sunrpc/xdr.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/net/sunrpc/xdr.c b/net/sunrpc/xdr.c > index b57cf9df4de8..08a85375b311 100644 > --- a/net/sunrpc/xdr.c > +++ b/net/sunrpc/xdr.c > @@ -945,8 +945,13 @@ inline void xdr_commit_encode(struct xdr_stream *xdr) > } > EXPORT_SYMBOL_GPL(xdr_commit_encode); > > -static __be32 *xdr_get_next_encode_buffer(struct xdr_stream *xdr, > - size_t nbytes) > +/* > + * The buffer space to be reserved crosses the boundary between > + * xdr->buf->head and xdr->buf->pages, or between two pages > + * in xdr->buf->pages. > + */ > +static noinline __be32 *xdr_get_next_encode_buffer(struct xdr_stream *xdr, > + size_t nbytes) > { > __be32 *p; > int space_left; > > >