From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752133AbdBFWoA (ORCPT ); Mon, 6 Feb 2017 17:44:00 -0500 Received: from mail-wm0-f66.google.com ([74.125.82.66]:34839 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751588AbdBFWn6 (ORCPT ); Mon, 6 Feb 2017 17:43:58 -0500 Date: Mon, 6 Feb 2017 23:43:54 +0100 From: Ingo Molnar To: Christoph Hellwig Cc: linux-kernel@vger.kernel.org, Andrew Morton , Linus Torvalds , Mike Galbraith , Oleg Nesterov , Peter Zijlstra , Thomas Gleixner Subject: Re: [PATCH 18/89] sched/core: Move task->mm handling methods to Message-ID: <20170206224354.GC6061@gmail.com> References: <1486387772-18837-1-git-send-email-mingo@kernel.org> <1486387772-18837-19-git-send-email-mingo@kernel.org> <20170206142842.GB17008@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170206142842.GB17008@infradead.org> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Christoph Hellwig wrote: > On Mon, Feb 06, 2017 at 02:28:21PM +0100, Ingo Molnar wrote: > > Move the following task->mm helper APIs into a new header file, > > , to further reduce the size and complexity > > of : > > Is there any good reason why they can't just go into linux/mm.h? So mm.h is pretty large already, and I wanted to preserve the natural API and header separation that was the result of these APIs being in sched.h. Many smaller headers are so much easier to maintain, and they are much more readable as well in my experience. mm.h and mm_types.h should probably be split up some more: on a defconfig kernel mm.i is about 18,800 lines long, with a size of 0.65 MB. There's a lot of wasted energy building all that again and again, while drivers typically need only a small fraction of those definitions. Not to mention that large headers typically result in lower code quality and poorer code organization as well. But we could move the new header to or so? Thanks, Ingo