From owner-freebsd-arm@FreeBSD.ORG Tue Mar 9 16:12:35 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 A7EDB106564A for ; Tue, 9 Mar 2010 16:12:35 +0000 (UTC) (envelope-from gjb@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 57DCB8FC14 for ; Tue, 9 Mar 2010 16:12:35 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 46FCCC42D1; Tue, 9 Mar 2010 17:15:03 +0100 (CET) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id pTCP7AtiYjuz; Tue, 9 Mar 2010 17:15:02 +0100 (CET) Received: from [10.0.0.75] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPA id 98FF8C41E7; Tue, 9 Mar 2010 17:15:02 +0100 (CET) Message-ID: <4B967370.4000206@semihalf.com> Date: Tue, 09 Mar 2010 17:12:32 +0100 From: Grzegorz Bernacki User-Agent: Thunderbird 2.0.0.16 (X11/20090618) MIME-Version: 1.0 To: Maks Verver References: <201003081819.o28IJNe6045140@casselton.net> <4B958D45.7040608@geocities.com> In-Reply-To: <4B958D45.7040608@geocities.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Tue, 09 Mar 2010 16:12:35 -0000 Maks Verver wrote: > On 03/08/2010 07:19 PM, Mark Tinguely wrote: >> Could you do this instead: >> >> This would give counts to make sure there is not a logic error in fix_cache. > > I tried this (adding initialization of the flag variable) and the > problem is triggered with (at least) these values: > > kwritable uwritable kentries uentries > 1 0 1 0 > 1 0 1 1 > 0 1 0 1 > 1 0 1 2 > It seems that probles is caused by shared mapping between kernel space and user space. We have page mapped as executable in user space and at the same time the same page is mapped in kernel space as writable (row 2 and 4 in table above). I am pretty sure that kernel mapping is from buffer space and the buffer was created to read .text segment from file to memory. I think that instead of turning off cache for user entries it is enough just to write-back and invalidate cache for kernel entry, assuming that code is already in buffer. In row 1 of table there is only one writable and executable kernel entry and I think it may be something allocated via kmem_alloc_wait() and it shouldn't not cause any trouble. In row 3 we have only one executable and writable user entry and it also shouldn't be a problem. I think that user stack is mapped as readable, writable and executable so maybe it was page from stack. grzesiek