From owner-freebsd-arch@FreeBSD.ORG Fri Sep 26 18:08:46 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 233D6BB9 for ; Fri, 26 Sep 2014 18:08:46 +0000 (UTC) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9EF70F19 for ; Fri, 26 Sep 2014 18:08:45 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id q1so3275912lam.7 for ; Fri, 26 Sep 2014 11:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=MuG6UdZE5iAXYS25rPUiq3LxcXA0AERkMXKmXAQ9k88=; b=L0wR5vcsBUys/uAhoFl2adpb24UiMsLzrJMzzvPYJKQr2vIItncNseevsi+NXz1GU1 VZ6v340g7iqjDPIGklJCJuZMnbjGW+szxz/LNjpYvi9dnh9vbnoSoAq7ApLAtiv4Qvox laXwJoB3XLhA4X5vYvZ+jYq1gZbS8ySyOxxi8InCBnd8mHhjPTasejh0ukjTHs/T63K2 a53eQ+Sbewwq+G5HWtwIIsNN9wXmgFHE9dhsKf4dhNoa1HjIdxs0pg0P67tLotGLZXf/ 7FeDyUhJeX5aOh0XVFFEJfTKDDcWkBLcFWYZFBsVAG+LaBMyLnXugOUTlOKoE8czO8t4 3TqQ== MIME-Version: 1.0 X-Received: by 10.152.22.100 with SMTP id c4mr3458772laf.0.1411754920710; Fri, 26 Sep 2014 11:08:40 -0700 (PDT) Received: by 10.25.15.95 with HTTP; Fri, 26 Sep 2014 11:08:40 -0700 (PDT) Reply-To: alc@freebsd.org In-Reply-To: References: Date: Fri, 26 Sep 2014 13:08:40 -0500 Message-ID: Subject: Re: vm_page_array and VM_PHYSSEG_SPARSE From: Alan Cox To: Svatopluk Kraus Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 18:08:46 -0000 On Wed, Sep 24, 2014 at 7:27 AM, Svatopluk Kraus wrote: > Hi, > > I and Michal are finishing new ARM pmap-v6 code. There is one problem we've > dealt with somehow, but now we would like to do it better. It's about > physical pages which are allocated before vm subsystem is initialized. > While later on these pages could be found in vm_page_array when > VM_PHYSSEG_DENSE memory model is used, it's not true for VM_PHYSSEG_SPARSE > memory model. And ARM world uses VM_PHYSSEG_SPARSE model. > > It really would be nice to utilize vm_page_array for such preallocated > physical pages even when VM_PHYSSEG_SPARSE memory model is used. Things > could be much easier then. In our case, it's about pages which are used for > level 2 page tables. In VM_PHYSSEG_SPARSE model, we have two sets of such > pages. First ones are preallocated and second ones are allocated after vm > subsystem was inited. We must deal with each set differently. So code is > more complex and so is debugging. > > Thus we need some method how to say that some part of physical memory > should be included in vm_page_array, but the pages from that region should > not be put to free list during initialization. We think that such > possibility could be utilized in general. There could be a need for some > physical space which: > > (1) is needed only during boot and later on it can be freed and put to vm > subsystem, > > (2) is needed for something else and vm_page_array code could be used > without some kind of its duplication. > > There is already some code which deals with blacklisted pages in vm_page.c > file. So the easiest way how to deal with presented situation is to add > some callback to this part of code which will be able to either exclude > whole phys_avail[i], phys_avail[i+1] region or single pages. As the biggest > phys_avail region is used for vm subsystem allocations, there should be > some more coding. (However, blacklisted pages are not dealt with on that > part of region.) > > We would like to know if there is any objection: > > (1) to deal with presented problem, > (2) to deal with the problem presented way. > Some help is very appreciated. Thanks > > As an experiment, try modifying vm_phys.c to use dump_avail instead of phys_avail when sizing vm_page_array. On amd64, where the same problem exists, this allowed me to use VM_PHYSSEG_SPARSE. Right now, this is probably my preferred solution. The catch being that not all architectures implement dump_avail, but my recollection is that arm does.