From owner-freebsd-arm@FreeBSD.ORG Mon Mar 22 16:26:11 2010 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E32E31065670; Mon, 22 Mar 2010 16:26:10 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4FC148FC16; Mon, 22 Mar 2010 16:26:10 +0000 (UTC) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id o2MGQ9m8074144; Mon, 22 Mar 2010 11:26:09 -0500 (CDT) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1269275169; bh=E877lMF7EvJ924qITcr0Uqsk7sVxIAEHAe9wJ4m2r2w=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=RDMQ9Kz1IxuhESvPH+G/TiGlNPOyXoVvQJ2BV+CLS3hkL5cleTpxvvh8DKFhWTh8E RlpfH8LHzGl6xrvj9YePdIepwLixDu3lvD9J48wxhABoS4ilRp4QI7VYboCnMrUteS zkxxZWkvR2OFN1E2938xeLeoHNpGHP2IQGh4W9n8= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id o2MGQ9n8074143; Mon, 22 Mar 2010 11:26:09 -0500 (CDT) (envelope-from tinguely) Date: Mon, 22 Mar 2010 11:26:09 -0500 (CDT) From: Mark Tinguely Message-Id: <201003221626.o2MGQ9n8074143@casselton.net> To: cognet@freebsd.org, tinguely@casselton.net In-Reply-To: <20100322150633.GA18277@ci0.org> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (casselton.net [127.0.0.1]); Mon, 22 Mar 2010 11:26:09 -0500 (CDT) Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 16:26:11 -0000 On Mon, 22 Mar 2010 16:06:33 Olivier Houchard said: > On Mon, Mar 22, 2010 at 09:55:04AM -0500, Mark Tinguely wrote: > > On Mon, 08 Mar 2010 16:50:58, Grzegorz Bernacki said: > > > > > This is probably caused by mechanism which turns of cache for shared pages. > > > When I add applied following path: > > > > > > diff --git a/sys/arm/arm/pmap.c b/sys/arm/arm/pmap.c > > > index 390dc3c..d17c0cc 100644 > > > --- a/sys/arm/arm/pmap.c > > > +++ b/sys/arm/arm/pmap.c > > > @@ -1401,6 +1401,8 @@ pmap_fix_cache(struct vm_page *pg, pmap_t pm, vm_offset_t va) > > > */ > > > > > > TAILQ_FOREACH(pv, &pg->md.pv_list, pv_list) { > > > + if (pv->pv_flags & PVF_EXEC) > > > + return; > > > /* generate a count of the pv_entry uses */ > > > if (pv->pv_flags & PVF_WRITE) { > > > if (pv->pv_pmap == pmap_kernel()) > > > > > > execution time of 'test' program is: > > > mv78100-4# time ./test > > > 5.000u 0.000s 0:05.40 99.8% 40+1324k 0+0io 0pf+0w > > > > > > and without this path is: > > > mv78100-4# time ./test > > > 295.000u 0.000s 4:56.01 99.7% 40+1322k 0+0io 0pf+0w > > > > > > > > > I think we need to handle executable pages in different way. > > > > > > grzesiek > > > > Good going Oliver and thank-you on the pmap_enter_pv kernel map patch Revision > > 205425. > > > > Last week, before this patch, Maks Verver was so kind to put some statements > > in the VM (vm_page_free_toq()) for the SheevaPlug because I could not cause > > these paths with the Gumstix emulator. Maks, could you add to > > vm_phys_free_pages(): > > > > if (m->md.pv_kva) > > + { > > + printf("vm_phys_free_pages: md.pv_kva 0x%08x\n", m->md.pv_kva); > > m->md.pv_kva = 0; > > + } > > > > Even on the Gumstix emulator with the current patch, pmap_fix_cache() still > > has many executable pages that have both a kernel and user pv_entry. Looks > > like something like the above patch is still needed. > > > I added a few printf and saw the same thing, however isn't assuming we > shouldn't modify the cache settings if the page is executable a bit dangerous ? > Or did I misread your patch ? > > Olivier The pmap_fix_cache() PVF_EXEC is Grzegorz's patch. In his defense, he later stated that we may need to flush the buffer. If the kernel map is a read-in page, the DMA probably did a POST-READ flush; the user page if was previously accessed - - could be stale and need to be invalidated. I was mostly mentioning there is another problem here besides dangling kernel allocations. Before I was pushing the removing the kernel allocation in pv_kva as a good thing; not only hoping the kernel entries in the PVF_EXEC were stale kernel entries, but also knowing that the removal of any stale kernel entries would be good for future data mappings too. Definitely, the kernel remap (more than 1 kernel mapping) case would indicate we need to turn off the caches. This situation could have been around for a while. Before FreeBSD 8.0, the kernel maps did not have pv_entrys, and the cache fix routines did not count them and we did not even know these user/kernel overlap existed. --Mark Tinguely.