From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 30 Apr 2002 01:31:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 30 Apr 2002 01:31:08 -0400 Received: from e31.co.us.ibm.com ([32.97.110.129]:13713 "EHLO e31.co.us.ibm.com") by vger.kernel.org with ESMTP id ; Tue, 30 Apr 2002 01:31:07 -0400 Date: Tue, 30 Apr 2002 11:01:08 +0530 From: Suparna Bhattacharya To: "Eric W. Biederman" Cc: linux-kernel@vger.kernel.org, marcelo@brutus.conectiva.com.br, linux-mm@kvack.org Subject: Re: [PATCH]Fix: Init page count for all pages during higher order allocs Message-ID: <20020430110108.A1275@in.ibm.com> Reply-To: suparna@in.ibm.com In-Reply-To: <20020429202446.A2326@in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 29, 2002 at 11:40:21AM -0600, Eric W. Biederman wrote: > Suparna Bhattacharya writes: > > > The call to set_page_count(page, 1) in page_alloc.c appears to happen > > only for the first page, for order 1 and higher allocations. > > This leaves the count for the rest of the pages in that block > > uninitialised. > > Actually it should be zero. > > This is deliberate because high order pages should not be referenced by > their partial pages. That sounds reasonable provided there is a way to identify the main page struct corresponding to an area that's part of a higher order page. > It might make sense to add a PG_large flag and > then in the immediately following struct page add a pointer to the next > page, so you can identify these pages by inspection. Doing something > similar to the PG_skip flag. Maybe different solutions could emerge for this in 2.4 and 2.5. Even a PG_partial flag for the partial pages will enable us to traverse back to the main page, and vice-versa to determine the partial pages covered by the main page, without any additional pointers. Is that an acceptable option for 2.4 ? (That's one more page flag ...) It would be good to have a way to determine the order directly from the page struct, without such traversals, at least in 2.5. > > Beyond that I get nervous, that people will treat it as endorsement of > doing a high order continuous allocation and then fragmenting the page. I don't think it would amount to such an endorsement. It's just a matter of replicating the settings from the main page to the partial pages - which might be considered an alternate protocol, though a little inefficient for really high orders. However, having the partial page counts zeroed out probably helps as a safeguard in some situations in view of the page count sanity checks. Or are there any scenarios where you forsee a problem/breakage ? Regards Suparna > > Eric