From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Lameter Subject: Re: [RFC 1/2] Protect larger order pages from breaking up Date: Fri, 16 Feb 2018 12:25:27 -0600 (CST) Message-ID: References: <20180216160110.641666320@linux.com> <20180216160121.519788537@linux.com> <20180216170354.vpbuugzqsrrfc4js@two.firstfloor.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: <20180216170354.vpbuugzqsrrfc4js-1g7Xle2YJi4/4alezvVtWx2eb7JE58TQ@public.gmane.org> Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Andi Kleen Cc: Mel Gorman , Matthew Wilcox , linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, Thomas Schoebel-Theuer , Rik van Riel , Michal Hocko , Guy Shattah , Anshuman Khandual , Michal Nazarewicz , Vlastimil Babka , David Nellans , Laura Abbott , Pavel Machek , Dave Hansen , Mike Kravetz List-Id: linux-rdma@vger.kernel.org On Fri, 16 Feb 2018, Andi Kleen wrote: > > First performance tests in a virtual enviroment show > > a hackbench improvement by 6% just by increasing > > the page size used by the page allocator to order 3. > > So why is hackbench improving? Is that just for kernel stacks? Less stack overhead. The large the page size the less metadata need to be handled. The freelists get larger and the chance of hitting the per cpu freelist increases. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f69.google.com (mail-it0-f69.google.com [209.85.214.69]) by kanga.kvack.org (Postfix) with ESMTP id E85366B0005 for ; Fri, 16 Feb 2018 13:26:32 -0500 (EST) Received: by mail-it0-f69.google.com with SMTP id w184so2386367ita.0 for ; Fri, 16 Feb 2018 10:26:32 -0800 (PST) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net. [69.252.207.38]) by mx.google.com with ESMTPS id x8si10546954itf.15.2018.02.16.10.26.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Feb 2018 10:26:32 -0800 (PST) Date: Fri, 16 Feb 2018 12:25:27 -0600 (CST) From: Christopher Lameter Subject: Re: [RFC 1/2] Protect larger order pages from breaking up In-Reply-To: <20180216170354.vpbuugzqsrrfc4js@two.firstfloor.org> Message-ID: References: <20180216160110.641666320@linux.com> <20180216160121.519788537@linux.com> <20180216170354.vpbuugzqsrrfc4js@two.firstfloor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Andi Kleen Cc: Mel Gorman , Matthew Wilcox , linux-mm@kvack.org, linux-rdma@vger.kernel.org, akpm@linux-foundation.org, Thomas Schoebel-Theuer , Rik van Riel , Michal Hocko , Guy Shattah , Anshuman Khandual , Michal Nazarewicz , Vlastimil Babka , David Nellans , Laura Abbott , Pavel Machek , Dave Hansen , Mike Kravetz On Fri, 16 Feb 2018, Andi Kleen wrote: > > First performance tests in a virtual enviroment show > > a hackbench improvement by 6% just by increasing > > the page size used by the page allocator to order 3. > > So why is hackbench improving? Is that just for kernel stacks? Less stack overhead. The large the page size the less metadata need to be handled. The freelists get larger and the chance of hitting the per cpu freelist increases. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org