On Sat, Mar 20, 2010 at 9:58 PM, FreeBSD Tinderbox
wrote:
> TB --- 2010-03-21 03:05:00 - tinderbox 2.6 running on
> freebsd-current.sentex.ca
> TB --- 2010-03-21 03:05:00 - starting HEAD tinderbox run for i386/i386
> TB --- 2010-03-21 03:05:00 - cleaning the object tree
> TB --- 2010-03-21 03:05:
TB --- 2010-03-21 03:05:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-03-21 03:05:00 - starting HEAD tinderbox run for i386/i386
TB --- 2010-03-21 03:05:00 - cleaning the object tree
TB --- 2010-03-21 03:05:29 - cvsupping the source tree
TB --- 2010-03-21 03:05:29 - /usr/bin/c
On Sat, Mar 20, 2010 at 5:55 PM, Alexander Best wrote:
> ok. i think i finally solved this riddle. the cause for the problem seems to
> have been my CPUTYPE in /etc/make.conf. it is set to 'native'. actually i've
> been using the 'native' keyword for years now and never had any problems with
> it,
on 21/03/2010 02:55 Alexander Best said the following:
> ok. i think i finally solved this riddle. the cause for the problem seems to
> have been my CPUTYPE in /etc/make.conf. it is set to 'native'. actually i've
> been using the 'native' keyword for years now and never had any problems with
> it,
ok. i think i finally solved this riddle. the cause for the problem seems to
have been my CPUTYPE in /etc/make.conf. it is set to 'native'. actually i've
been using the 'native' keyword for years now and never had any problems with
it, but it seems a recent commit broke 'native' as CPUTYPE. for me
i still haven't been able to do a buildworld without cc segfaulting. :(
if i repeat the cc operation that segfaulted during buildworld with cc under
/usr/bin everything works fine. the segfault only occurs during buildworld
with the bootstrapped version of cc under /usr/ob/usr/src/tmp/usr/bin/cc.
Ivan Voras wrote:
Julian Elischer wrote:
Alexander Motin wrote:
Scott Long wrote:
On Mar 20, 2010, at 11:53 AM, Matthew Dillon wrote:
Diminishing returns get hit pretty quickly with larger MAXPHYS
values.
As long as the I/O can be pipelined the reduced transaction rate
becomes less
On Sat, Mar 20, 2010 at 03:44:46PM +, Anton Shterenlikht wrote:
> On Sat, Mar 20, 2010 at 07:27:43AM -0400, jhell wrote:
> >
> > On Fri, 19 Mar 2010 17:15, Anton Shterenlikht wrote:
> > In Message-Id: <20100319211535.ga76...@mech-cluster241.men.bris.ac.uk>
> >
> > > On Thu, Mar 18, 2010 at 11
Alexander Motin wrote:
Scott Long wrote:
On Mar 20, 2010, at 11:53 AM, Matthew Dillon wrote:
Diminishing returns get hit pretty quickly with larger MAXPHYS values.
As long as the I/O can be pipelined the reduced transaction rate
becomes less interesting when the transaction rate is les
2010/3/20 Alexander Motin
> Hi.
>
> With set of changes done to ATA, CAM and GEOM subsystems last time we
> may now get use for increased MAXPHYS (maximum physical I/O size) kernel
> constant from 128K to some bigger value.
[snip]
> All above I have successfully tested last months with MAXPHY
Scott Long wrote:
> On Mar 20, 2010, at 11:53 AM, Matthew Dillon wrote:
>>Diminishing returns get hit pretty quickly with larger MAXPHYS values.
>>As long as the I/O can be pipelined the reduced transaction rate
>>becomes less interesting when the transaction rate is less than a
>>c
On Sat, Mar 20, 2010 at 6:53 PM, Matthew Dillon
wrote:
>
> :All above I have successfully tested last months with MAXPHYS of 1MB on
> :i386 and amd64 platforms.
> :
> :So my questions are:
> :- does somebody know any issues denying increasing MAXPHYS in HEAD?
> :- are there any specific opinions a
TB --- 2010-03-20 16:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-03-20 16:40:00 - starting HEAD tinderbox run for i386/i386
TB --- 2010-03-20 16:40:00 - cleaning the object tree
TB --- 2010-03-20 16:40:24 - cvsupping the source tree
TB --- 2010-03-20 16:40:24 - /usr/bin/c
:Pardon my ignorance, but wouldn't so much KVM make small embedded
:devices like Soekris boards with 128 MB of physical RAM totally unusable
:then? On my net4801, running RELENG_8:
:
:vm.kmem_size: 40878080
:
:hw.physmem: 125272064
:hw.usermen: 84840448
:hw.realmem: 134217728
KVM != physical m
On Mar 20, 2010, at 11:53 AM, Matthew Dillon wrote:
>
> :All above I have successfully tested last months with MAXPHYS of 1MB on
> :i386 and amd64 platforms.
> :
> :So my questions are:
> :- does somebody know any issues denying increasing MAXPHYS in HEAD?
> :- are there any specific opinions abou
:All above I have successfully tested last months with MAXPHYS of 1MB on
:i386 and amd64 platforms.
:
:So my questions are:
:- does somebody know any issues denying increasing MAXPHYS in HEAD?
:- are there any specific opinions about value? 512K, 1MB, MD?
:
:--
:Alexander Motin
(nswbuf * MAX
On Sat, Mar 20, 2010 at 07:27:43AM -0400, jhell wrote:
>
> On Fri, 19 Mar 2010 17:15, Anton Shterenlikht wrote:
> In Message-Id: <20100319211535.ga76...@mech-cluster241.men.bris.ac.uk>
>
> > On Thu, Mar 18, 2010 at 11:29:36AM -0400, jhell wrote:
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash:
Hi.
With set of changes done to ATA, CAM and GEOM subsystems last time we
may now get use for increased MAXPHYS (maximum physical I/O size) kernel
constant from 128K to some bigger value. Increasing it allows to improve
performance and reduce processing overhead for large I/O operations.
Potential
On Fri, 19 Mar 2010 17:15, Anton Shterenlikht wrote:
In Message-Id: <20100319211535.ga76...@mech-cluster241.men.bris.ac.uk>
On Thu, Mar 18, 2010 at 11:29:36AM -0400, jhell wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 17 Mar 2010 12:32, Anton Shterenlikht wrote:
In Message-Id
TB --- 2010-03-20 05:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-03-20 05:40:00 - starting HEAD tinderbox run for i386/i386
TB --- 2010-03-20 05:40:00 - cleaning the object tree
TB --- 2010-03-20 05:40:29 - cvsupping the source tree
TB --- 2010-03-20 05:40:29 - /usr/bin/c
20 matches
Mail list logo
