freebsd-arm Digest, Vol 206, Issue 4
freebsd-a...@freebsd.org
freeb...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
or, via email, send a message with subject or body 'help' to
freebsd-a...@freebsd.org
You can reach the person managing the list at
freebsd-...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-arm digest..."
Today's Topics:
1. Re: Performance of SheevaPlug on 8-stable (Grzegorz Bernacki)
2. Re: Performance of SheevaPlug on 8-stable (Mark Tinguely)
3. [head tinderbox] failure on arm/arm (FreeBSD Tinderbox)
----------------------------------------------------------------------
Message: 1
Date: Tue, 09 Mar 2010 17:12:32 +0100
From: Grzegorz Bernacki <g...@semihalf.com>
Subject: Re: Performance of SheevaPlug on 8-stable
To: Maks Verver <maksv...@geocities.com>
Cc: freeb...@freebsd.org
Message-ID: <4B967370...@semihalf.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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
------------------------------
Message: 2
Date: Tue, 9 Mar 2010 12:11:42 -0600 (CST)
From: Mark Tinguely <ting...@casselton.net>
Subject: Re: Performance of SheevaPlug on 8-stable
To: g...@semihalf.com, maksv...@geocities.com
Cc: freeb...@freebsd.org
Message-ID: <201003091811....@casselton.net>
Thank-you for running the pmap_fix_cache() counts on executable.
They were what I expected, but it does not point to why.
If anyone thinks we are still leaking kernel allocations, I would
think the place for a conditional printf statement where the md.pv_kva
is non-zero in vm_page_free_toq() where the hold_count is zero.
--Mark Tinguely.
------------------------------
Message: 3
Date: Wed, 10 Mar 2010 00:41:34 GMT
From: FreeBSD Tinderbox <tind...@freebsd.org>
Subject: [head tinderbox] failure on arm/arm
To: FreeBSD Tinderbox <tind...@freebsd.org>, <cur...@freebsd.org>,
<a...@freebsd.org>
Message-ID: <201003100041....@freebsd-current.sentex.ca>
TB --- 2010-03-10 00:40:01 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-03-10 00:40:01 - starting HEAD tinderbox run for arm/arm
TB --- 2010-03-10 00:40:01 - cleaning the object tree
TB --- 2010-03-10 00:40:16 - cvsupping the source tree
TB --- 2010-03-10 00:40:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile
TB --- 2010-03-10 00:40:34 - building world
TB --- 2010-03-10 00:40:34 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-03-10 00:40:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-03-10 00:40:34 - TARGET=arm
TB --- 2010-03-10 00:40:34 - TARGET_ARCH=arm
TB --- 2010-03-10 00:40:34 - TZ=UTC
TB --- 2010-03-10 00:40:34 - __MAKE_CONF=/dev/null
TB --- 2010-03-10 00:40:34 - cd /src
TB --- 2010-03-10 00:40:34 - /usr/bin/make -B buildworld
>>> World build started on Wed Mar 10 00:40:34 UTC 2010
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
[...]
===> secure/libexec/sftp-server (cleandir)
rm -f sftp-server sftp-server.o sftp-common.o sftp-server-main.o roaming_dummy.o sftp-server.8.gz sftp-server.8.cat.gz
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> secure/libexec/ssh-keysign (cleandir)
rm -f ssh-keysign ssh-keysign.o readconf.o roaming_dummy.o ssh-keysign.8.gz ssh-keysign.8.cat.gz
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> secure/libexec/ssh-pkcs11-helper (cleandir)
cd: can't cd to /src/secure/libexec/ssh-pkcs11-helper
*** Error code 2
Stop in /src/secure/libexec.
*** Error code 1
Stop in /src/secure.
*** Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
*** Error code 1
Stop in /src.
TB --- 2010-03-10 00:41:34 - WARNING: /usr/bin/make returned exit code 1
TB --- 2010-03-10 00:41:34 - ERROR: failed to build world
TB --- 2010-03-10 00:41:34 - 34.23 user 20.68 system 93.66 real
http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full
------------------------------
End of freebsd-arm Digest, Vol 206, Issue 4
*******************************************