From owner-freebsd-arch@FreeBSD.ORG Fri Sep 26 19:46:56 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 C135B13A for ; Fri, 26 Sep 2014 19:46:56 +0000 (UTC) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) (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 8DE4DC0A for ; Fri, 26 Sep 2014 19:46:56 +0000 (UTC) Received: by mail-pd0-f175.google.com with SMTP id v10so12326630pde.6 for ; Fri, 26 Sep 2014 12:46:55 -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=upMA5FeGjr3Oh1Uu35W2YUNJu0U4GsFOyzGVJPb89aY=; b=KWRd+YGj4csBG6L5OnoJniOuKFP+XJXK6qdV4LvhhW8idRmnk9qLLzj6WDMbvcaDaX Gs3k2bwGtc2BnO9tsVAotgxTiBGaQfh8O84U/sP+xkp3CPMhBdSWpTWLo3Vk/KZ+HghL i2heQlnFkXkhZtn2iExaqQ2KOpjgQPw3e7TI61dm14jcPbk7wS3hwKE2gTihj7avXGZv 6X7/tP+rt1mKc86GcpXeAS472EcpHEym7vTxkt2dTJJx1bJlipPIK/IZzelrp1iDcvK3 ArDSjWAu+UNanU+VViyP6515N3+suQkIMv31mkVG6dEWU7hJ7Trh6x6i+n3ZQ5GaClZN jPIQ== X-Gm-Message-State: ALoCoQnlyYIJ//b75Oq/tq3J26sgwO17fTMrDI4/vzmWN7IQXy+0t6Q4iU4c1CpaicJMC3jLrwmX X-Received: by 10.66.119.175 with SMTP id kv15mr35196584pab.30.1411760815195; Fri, 26 Sep 2014 12:46:55 -0700 (PDT) Received: from [172.20.12.175] ([12.145.98.24]) by mx.google.com with ESMTPSA id rz8sm5627441pbc.63.2014.09.26.12.46.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Sep 2014 12:46:54 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_1A9EC1DD-0BDF-4731-8C48-D328770FF63A"; 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 12:46:51 -0700 Message-Id: <87094DEA-B403-49ED-9C63-A06FBF46D7EE@bsdimp.com> References: To: alc@freebsd.org X-Mailer: Apple Mail (2.1878.6) Cc: Svatopluk Kraus , 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 19:46:56 -0000 --Apple-Mail=_1A9EC1DD-0BDF-4731-8C48-D328770FF63A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 26, 2014, at 11:08 AM, Alan Cox wrote: > On Wed, Sep 24, 2014 at 7:27 AM, Svatopluk Kraus = wrote: >=20 >> 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. >>=20 >> 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, >>=20 >> (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.) >>=20 >> 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 >>=20 >>=20 >=20 > 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. For those architectures where it isn=92t implemented now, it is easy to = implement=85. Warner --Apple-Mail=_1A9EC1DD-0BDF-4731-8C48-D328770FF63A 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 iQIcBAEBCgAGBQJUJcKrAAoJEGwc0Sh9sBEAGhsQAKhhqwIHhgu9Isb49arTxque MZJICVBZ2Xhx5Sl2wnCVt30Yvu5dCCgjrayb1gNMG0e+GOFLACW9CtmFJSMKeAub Aqyz3tz6ifJlZj55C/Td7XBDyS2CeoV8xtcGCF6p4Mxocdy45Gg8yL9tvBMPWCSL so43A32oJQsz1wtX3nJ8f9g6wekgCZ9pbFwSWPeAKtYZUdvYSyjJg+IZI9bhD0iZ cDt0fdE2a8IRyo9GpHku3kKvnTkcLE7MvS5X392o1MKMui2XNTYTVNLJXG+dgfGj K+SNn1PT/piUXH20C62frc0eovvLeZYm41l5q2zH+b0LxWsNZlIn6StjF45PZcFA +L8MHBNFuS4h9ykbzZ4DRuXGyRZ/h+vTNIjxVwl0Rrvo+lEgMAVIc0QzDOGs2Wzz dQE+NY/OL3tVkDLdbvIF+D2VtB/DlTHb0hGfZp33PSn+KRZh5GmQG3AUQbiDbxXw PHZzmYFL3JiuNNNcC890pag76bZOsZb1uSlHivQ7JhixQH960X1xZZpLKsci/Wif LD8kebDPjcicJWDSHRS9dwPOt8AYyChuDI4vW6zovZRsAWEtjtzyp0v368nR8XB9 NkCKRmpLzqhCIdx0RCv1EYgnQVSkPg6/9Va3RyljQ3S9sWZzPIhuvx1to0xLFJe5 T1582JFnqWZFyHHoQ7z2 =yzPg -----END PGP SIGNATURE----- --Apple-Mail=_1A9EC1DD-0BDF-4731-8C48-D328770FF63A--