Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp559034pxf; Wed, 17 Mar 2021 10:27:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxa5H4mRlPozJBGb70A0mo/UujcO6X4fyq2ohc2wLJrFj6SZ3f5DMexErT6+Khn9AAh5hEm X-Received: by 2002:a17:907:76c7:: with SMTP id kf7mr35891622ejc.470.1616002061025; Wed, 17 Mar 2021 10:27:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616002061; cv=none; d=google.com; s=arc-20160816; b=k0o0jOtoHIu4t5r4Oou5WtdriUr6W5NvPionudwaBBiQlBVeWTLzts1rurZFME2Z85 r9tqFoUxYmV2rvOeAo5jdiVENeEcvTbl5quOSFtVnuzVN22U2jCnIcZmXGzcU6U1rCsM 2juFG4ZmRb0gi+mqoRV3uLImljPeV6kBWaK/fG0lc9O0gphGq6JfZ2LqGgim1JU0geSL 1qbLIxwyQGMBDrNV4vGd8J3YrfTL5F5oxEJBFWVMNPrtQaFoUITtEkYgNX6mNMG1xikS BsFp8H/Bgm33/lF5USoYBwOKJPNlbnJo7Pk3jT8GS/p/0+TBMCFYZMNR56E4W4VN+3Wh 4ZDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=0NhvvvHmyT/STmm3le4+4DkjnpET7hVpc/Bo+3kH164=; b=KxqrY1UT1LXVyJTdhmYqAHK3HQE2GvbCF7GEO8M529uEF9cXN21S8+fP0MAMAHSQTk dubQHgnhi0bX9k5ciWr7tgaEAtp59vCNsNsgzbZ4gfeKVw/fG2EWch7mTt3pCrn7IZ3J 6svIDUCod87OzbX32DoK0f1MGwC9vxN+tfXeIjmFhitRBwKwYGll7y0YtLquS2RCvTqH uhDg/+/6wKUNt/+os5F38CxbQr1s/QPvLxiZc31DwhZ8/AW6nbGu6NicNfNecjnFnJI5 fDxLuCKTT9P7S1deVGG32opO4Ve5AM+tLTzdrkKwq1C5DIo0WSeoUq6alZTw2qUn2oCF PVAA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=a1O71oXM; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m24si18002460eda.304.2021.03.17.10.27.10; Wed, 17 Mar 2021 10:27:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=a1O71oXM; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231682AbhCQRVV (ORCPT + 99 others); Wed, 17 Mar 2021 13:21:21 -0400 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:24920 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231809AbhCQRT4 (ORCPT ); Wed, 17 Mar 2021 13:19:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616001596; 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=0NhvvvHmyT/STmm3le4+4DkjnpET7hVpc/Bo+3kH164=; b=a1O71oXMDp4cYxvSkj0VCBZBfffi38YTIoCswvmmJulK2QGwT+4Rd5y1s08wwfJnnrX/fG BRH/EoARpkIyFeFPAj/tluYyeL1LeFhBfv+FDGlIdjz4n8IY2DvSf1jymUs2k2r1pGTraB ET0inFYaiunNFmMQB5d8WJVQq8OhRdQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-594-5zsbSrqYM2e8rRrQeWjybg-1; Wed, 17 Mar 2021 13:19:53 -0400 X-MC-Unique: 5zsbSrqYM2e8rRrQeWjybg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0954A9CC00; Wed, 17 Mar 2021 17:19:51 +0000 (UTC) Received: from carbon (unknown [10.36.110.30]) by smtp.corp.redhat.com (Postfix) with ESMTP id 02EB919C45; Wed, 17 Mar 2021 17:19:44 +0000 (UTC) Date: Wed, 17 Mar 2021 18:19:43 +0100 From: Jesper Dangaard Brouer To: Alexander Lobakin Cc: Mel Gorman , Andrew Morton , Chuck Lever , Christoph Hellwig , Alexander Duyck , Matthew Wilcox , LKML , Linux-Net , Linux-MM , Linux-NFS , brouer@redhat.com Subject: Re: [PATCH 0/7 v4] Introduce a bulk order-0 page allocator with two in-tree users Message-ID: <20210317181943.1a339b1e@carbon> In-Reply-To: <20210317165220.808975-1-alobakin@pm.me> References: <20210312154331.32229-1-mgorman@techsingularity.net> <20210317163055.800210-1-alobakin@pm.me> <20210317173844.6b10f879@carbon> <20210317165220.808975-1-alobakin@pm.me> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Wed, 17 Mar 2021 16:52:32 +0000 Alexander Lobakin wrote: > From: Jesper Dangaard Brouer > Date: Wed, 17 Mar 2021 17:38:44 +0100 > > > On Wed, 17 Mar 2021 16:31:07 +0000 > > Alexander Lobakin wrote: > > > > > From: Mel Gorman > > > Date: Fri, 12 Mar 2021 15:43:24 +0000 > > > > > > Hi there, > > > > > > > This series is based on top of Matthew Wilcox's series "Rationalise > > > > __alloc_pages wrapper" and does not apply to 5.12-rc2. If you want to > > > > test and are not using Andrew's tree as a baseline, I suggest using the > > > > following git tree > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/mel/linux.git mm-bulk-rebase-v4r2 > > > > > > I gave this series a go on my setup, it showed a bump of 10 Mbps on > > > UDP forwarding, but dropped TCP forwarding by almost 50 Mbps. > > > > > > (4 core 1.2GHz MIPS32 R2, page size of 16 Kb, Page Pool order-0 > > > allocations with MTU of 1508 bytes, linear frames via build_skb(), > > > GRO + TSO/USO) > > > > What NIC driver is this? > > Ah, forgot to mention. It's a WIP driver, not yet mainlined. > The NIC itself is basically on-SoC 1G chip. Hmm, then it is really hard to check if your driver is doing something else that could cause this. Well, can you try to lower the page_pool bulking size, to test the theory from Wilcox that we should do smaller bulking to avoid pushing cachelines into L2 when walking the LRU list. You might have to go as low as bulk=8 (for N-way associative level of L1 cache). In function: __page_pool_alloc_pages_slow() adjust variable: const int bulk = PP_ALLOC_CACHE_REFILL; -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer