From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262170AbUKQLog (ORCPT ); Wed, 17 Nov 2004 06:44:36 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262286AbUKQLoL (ORCPT ); Wed, 17 Nov 2004 06:44:11 -0500 Received: from mx1.redhat.com ([66.187.233.31]:49351 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S262284AbUKQLnn (ORCPT ); Wed, 17 Nov 2004 06:43:43 -0500 From: David Howells In-Reply-To: References: <2315.1100630906@redhat.com> To: Linus Torvalds Cc: akpm@osdl.org, hch@infradead.org, linux-kernel@vger.kernel.org Subject: Re: [RFC] Making compound pages mandatory User-Agent: EMH/1.14.1 SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Date: Wed, 17 Nov 2004 11:43:09 +0000 Message-ID: <17633.1100691789@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > > Do you have any objection to compound pages being made mandatory, even > > without HUGETLB support? > > I haven't really looked into it, so I cannot make an informed decision. > How big is the overhead? And what's the _point_, since we don't seem to > need them normally, but the code is there for people who _do_ need them? The reason they might be useful under uClinux is that access_process_vm() mucks around with pages in the middle of a high-order allocation. Technically, with what was integrated to support uClinux and with the patch I added, it's not actually necessary to use compound pages, I think, if only because access_process_vm() provides some protections against munmap() and exit(). However, that doesn't mean there isn't something I and the uClinux community haven't noticed, or that situations won't arise in the future where the current scheme is going to cause the kernel to explode. > I don't generally like two paths, but quite frankly, I consider the > non-compound case the regular case right now. How expensive does the > compound pages end up being? Is it just one more pointer chase on every > get_page/put_page, or what? No, it's not. In put_page() it's _always_ going to be at least one more pointer chase, and sometimes it's going to be two more; though the dcache may offset this. put_page() refers not only to data in the first real page of a compound page, but the second real page too. Furthermore, put_page() becomes out of line. This means you've got register clobberage and the mechanisms of function calls to deal with. Also you've got more conditional instructions. I would propose also that the condition checking for PG_compound be marked unlikely(). > Does anybody have numbers for before/after that are otherwise comparable? I don't. However, the people hassling me about it might (hch for one). David