From owner-freebsd-current@FreeBSD.ORG Sun Oct 5 08:57:59 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 15D6F3DA; Sun, 5 Oct 2014 08:57:59 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7C83E86A; Sun, 5 Oct 2014 08:57:58 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s958vrt8068472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Oct 2014 11:57:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s958vrt8068472 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s958vrON068471; Sun, 5 Oct 2014 11:57:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 5 Oct 2014 11:57:53 +0300 From: Konstantin Belousov To: stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: About pmap_mapdev() & pmap_unmapdev() Message-ID: <20141005085753.GX26076@kib.kiev.ua> References: <20141004092030.GP26076@kib.kiev.ua> <20141004.205335.1782700760623869892.okuno.kohji@jp.panasonic.com> <20141004155803.GQ26076@kib.kiev.ua> <20141005.131512.606074419488263735.okuno.kohji@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141005.131512.606074419488263735.okuno.kohji@jp.panasonic.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 08:57:59 -0000 On Sun, Oct 05, 2014 at 01:15:12PM +0900, Kohji Okuno wrote: > Hi, > > > On Sat, Oct 04, 2014 at 08:53:35PM +0900, Kohji Okuno wrote: > >> Hi Konstantin, > >> > >> Thank you for your prompt response. > >> I will test and report from next monday. > >> > >> >> In addtion, I have one question. > >> >> In current and 10-stable, is vm_map_delete() called by kva_free()? > >> > No, kva_free() only releases the vmem backing, leaving the page > >> > tables intact. This is why I only did the stable/9 patch. > >> > >> Where are PTEs allocated by pmap_mapdev() freed in current and 10-stable? > >> Could you please explain me? > > They are not freed. The removal of the vmem which covers the address > > space managed by corresponding ptes, allows the reuse of both KVA region > > and corresponding PTEs in the tables. The only concern with the resident > > page tables is to avoid two kva_alloc() to step over each other, and > > this is ensured by vmem. > > I agree that normal pages are reusable. But, since the pages mapped by > pmap_mapdev() are concerned with the physicall address of device (For > example: video memory), these PTEs aren't reusable, I think. > So, should we free these PTEs by pmap_unmapdev()? There is no hold on any physical pages which were referenced by the ptes. The only thing which is left out are the records in the page tables which map the KVA to said device memory. It is harmless. When the KVA is reused, the ptes in page tables are overwritten. It might be argued that clearing PTEs, or at least removing the PG_V bit catches erronous unintended accesses to the freed range, but by the cost of the overhead of re-polluting the caches. And since clearing is not effective without doing TLB flush, which requires broadcast IPI, it is more trouble than advantage.