From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966344AbdADLK5 (ORCPT ); Wed, 4 Jan 2017 06:10:57 -0500 Received: from outbound-smtp10.blacknight.com ([46.22.139.15]:50105 "EHLO outbound-smtp10.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966228AbdADLKw (ORCPT ); Wed, 4 Jan 2017 06:10:52 -0500 From: Mel Gorman To: Jesper Dangaard Brouer Cc: Linux Kernel , Linux-MM , Mel Gorman Subject: [RFC PATCH 0/4] Fast noirq bulk page allocator Date: Wed, 4 Jan 2017 11:10:45 +0000 Message-Id: <20170104111049.15501-1-mgorman@techsingularity.net> X-Mailer: git-send-email 2.11.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This series is motivated by a conversation led by Jesper Dangaard Brouer at the last LSF/MM proposing a generic page pool for DMA-coherent pages. Part of his motivation was due to the overhead of allocating multiple order-0 that led some drivers to use high-order allocations and splitting them which can be very slow if high-order pages are unavailable. This long-overdue series aims to show that raw bulk page allocation can be achieved relatively easily without introducing a completely new allocator. A new generic page pool allocator would then ideally focus on just the DMA-coherent part. The first two patches in the series restructure the allocator such that it's relatively easy to build a bulk page allocator. The third patch alters the per-cpu alloctor to make it exclusive to !irq requests. This cuts allocation/free overhead by roughly 30% but it may not be noticable to anyone other than users of high-speed networks (I'm not one). The fourth patch introduces a bulk page allocator with no in-kernel users as an example for Jesper and others who want to build a page allocator for DMA-coherent pages. It hopefully is relatively easy to modify this API and the one core function to get the semantics they require. Note that Patch 3 is not required for patch 4 but it may be desirable if the bulk allocations happen from !IRQ context. include/linux/gfp.h | 23 ++++ mm/page_alloc.c | 329 ++++++++++++++++++++++++++++++++++++---------------- 2 files changed, 254 insertions(+), 98 deletions(-) -- 2.11.0