From owner-freebsd-arch@FreeBSD.ORG Fri Sep 26 17:41:14 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 C27F9742 for ; Fri, 26 Sep 2014 17:41:14 +0000 (UTC) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) (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 90F7EC18 for ; Fri, 26 Sep 2014 17:41:14 +0000 (UTC) Received: by mail-pd0-f178.google.com with SMTP id ft15so13085220pdb.23 for ; Fri, 26 Sep 2014 10:41:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=8Pxoh2P6+ydqjkzum32KfkaWqMxBLCwoZbsL9IGOvQ4=; b=BS/KLW3IxRb2zyypV02jUPqi8V+mGBiqRL19CaJMGog9PW+ZnF89rPGGsvVye5fyV7 Vdr8g5Y9e01QMaTviq7lPDXbGu/CYi7s+dZgaQyyUwHiDxVcocqHoxI/5YDzIUoDuKCf VgRYWkWkUZzNi5I5Mip/OfdfNGzS9Z3ELepVeLVOgjISiTrr63Jldfit7qPzbeXA5d5H qWc8EXEy/oQ8s405NJnP3QqwJikAT1uZHaLm/OQBzyIRtRhzvrcj7pALtltfhdoQiY0v 0sFKNRYsh3cgjZ2uIF1lFtIC3l3Xtaa6GGyktPoax8UzILpzV33XKbRSM4JDRGwKUJ0E Ac5w== X-Gm-Message-State: ALoCoQmG8tuXf/DaJVXOpmM9F3B5BuxzyMVeL6Xml7fUIT7he2uKSsQApZlGCiJoLKSIm3ebS4Mq X-Received: by 10.70.21.228 with SMTP id y4mr34194257pde.19.1411753273219; Fri, 26 Sep 2014 10:41:13 -0700 (PDT) Received: from [172.24.39.159] ([64.186.236.200]) by mx.google.com with ESMTPSA id tc5sm5458677pbc.51.2014.09.26.10.41.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Sep 2014 10:41:12 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_D7062E12-134B-4F23-AC54-6CC8C3C96A92"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: vm_page_array and VM_PHYSSEG_SPARSE From: Warner Losh In-Reply-To: Date: Fri, 26 Sep 2014 10:41:12 -0700 Message-Id: <2F2CA5C3-3F0A-4F7D-B9C5-E78DC9E9F92A@bsdimp.com> References: To: Svatopluk Kraus X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arch@freebsd.org 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 17:41:14 -0000 --Apple-Mail=_D7062E12-134B-4F23-AC54-6CC8C3C96A92 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 24, 2014, at 5:27 AM, Svatopluk Kraus wrote: > Hi, >=20 > 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. >=20 > 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. That would be nice. Right now the memory allocation code early in the = ARM code is very simplistic on all the platforms I=92ve looked at: we get a base = address and just increment it as we allocate the page tables, etc. It would be = straight forward to add calls to note all of these pages. > 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: >=20 > (1) is needed only during boot and later on it can be freed and put to = vm > subsystem, I don=92t think we have any pages that are like this. The pages that = could be freed today are just wasted. > (2) is needed for something else and vm_page_array code could be used > without some kind of its duplication. >=20 > 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.) Usually just not putting them into the free pool would be enough to keep = the vm=92s hands off of them. What are you proposing over that? > We would like to know if there is any objection: >=20 > (1) to deal with presented problem, > (2) to deal with the problem presented way. > Some help is very appreciated. Thanks I generally like the idea, so long as the vm_page_array doesn=92t eat a = lot of memory. In the early days, we went with SPARSE, I believe, to avoid = having huge arrays for those platforms whose memory started at 0xfxxxxxxx or 0xexxxxxxx=85 But memory here is a bit hazy... Warner --Apple-Mail=_D7062E12-134B-4F23-AC54-6CC8C3C96A92 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUJaU4AAoJEGwc0Sh9sBEAAi4QAIZ+XlJ+3BWdd3GJq1mOCK2N fp/re18Wrp8aNqPsBB4xxeO4Ju18+1tuO/BP+4zvuBmnBt5YkWwXaDUpZlSYZE5F BsjOBOvAV1COJSYhavxFOCHu7Uguv5oOqPkcAiW8nDmPeCcWzU0T8aVZOQ56ZW9r 2MCadr7nzJNWS3hsZ2FWNZmDxeHhY2+t+NSF1s7oL5WrzGTYzlgFvbQhtgMx1vzJ pdrUsJXqMnWk2b1R8OveN58gGCDJFy2kmHQGLsetCe4A0XI4uKom+8gsPgHEbH6Z Hhhe4x82CKXVHhs9fwvV862c905lI4cPRLcbPSx2jUAHFdCxZeQxHJFBuXTYhfnp 3FWrMbAywCKlOi0WiZgLnjYo56dlKFKhavTbjMIBd05LC7rwo8CnUJPEjHNDuhVR NpGQDE4jrSp5j4haWEDroyu1BNH4QpwGsbbk4bWMJUJLBOLJHNvff311z6yfwRSr PFsxO09HAZaXcSd9b9BRrfdnKI1AJ6iGxQaJ2cA7wgz/pdGO5ml+BOsOKQxFdS7p KIGDMmJjHbp0mzS2cKiaGDbxIbbniczS8eYPwDxIPwIGHTQ103cosSC3/IUCkCPt /5Em+DlCu+DP3Gfy9kItHhCXdb3lIIw4YK7M3u37E36ayaH2+7dAwoQwUkkm0ODn lM70Nzw63G5nBwQqvWhi =ATk/ -----END PGP SIGNATURE----- --Apple-Mail=_D7062E12-134B-4F23-AC54-6CC8C3C96A92--