Date: Tue, 09 Mar 2010 17:12:32 +0100 From: Grzegorz Bernacki <gjb@semihalf.com> To: Maks Verver <maksverver@geocities.com> Cc: freebsd-arm@freebsd.org Subject: Re: Performance of SheevaPlug on 8-stable Message-ID: <4B967370.4000206@semihalf.com> In-Reply-To: <4B958D45.7040608@geocities.com> References: <201003081819.o28IJNe6045140@casselton.net> <4B958D45.7040608@geocities.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Maks Verver wrote: > On 03/08/2010 07:19 PM, Mark Tinguely wrote: >> Could you do this instead: >> <code> >> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B967370.4000206>