Re: Time to increase MAXPHYS?

2017-06-03 Thread Warner Losh
On Sat, Jun 3, 2017 at 11:28 PM, Warner Losh wrote: > > > On Sat, Jun 3, 2017 at 9:55 PM, Allan Jude wrote: > >> On 2017-06-03 22:35, Julian Elischer wrote: >> > On 4/6/17 4:59 am, Colin Percival wrote: >> >> On January 24, 1998, in what was later renumbered to SVN r32724, dyson@ >> >> wrote: >>

Re: Time to increase MAXPHYS?

2017-06-03 Thread Warner Losh
On Sat, Jun 3, 2017 at 2:59 PM, Colin Percival wrote: > On January 24, 1998, in what was later renumbered to SVN r32724, dyson@ > wrote: > > Add better support for larger I/O clusters, including larger physical > > I/O. The support is not mature yet, and some of the underlying > implementation >

Re: Time to increase MAXPHYS?

2017-06-03 Thread Warner Losh
On Sat, Jun 3, 2017 at 9:55 PM, Allan Jude wrote: > On 2017-06-03 22:35, Julian Elischer wrote: > > On 4/6/17 4:59 am, Colin Percival wrote: > >> On January 24, 1998, in what was later renumbered to SVN r32724, dyson@ > >> wrote: > >>> Add better support for larger I/O clusters, including larger

Re: Time to increase MAXPHYS?

2017-06-03 Thread Allan Jude
On 2017-06-03 22:35, Julian Elischer wrote: > On 4/6/17 4:59 am, Colin Percival wrote: >> On January 24, 1998, in what was later renumbered to SVN r32724, dyson@ >> wrote: >>> Add better support for larger I/O clusters, including larger physical >>> I/O. The support is not mature yet, and some of

Re: Time to increase MAXPHYS?

2017-06-03 Thread Julian Elischer
On 4/6/17 4:59 am, Colin Percival wrote: On January 24, 1998, in what was later renumbered to SVN r32724, dyson@ wrote: Add better support for larger I/O clusters, including larger physical I/O. The support is not mature yet, and some of the underlying implementation needs help. However, suppo

Time to increase MAXPHYS?

2017-06-03 Thread Colin Percival
On January 24, 1998, in what was later renumbered to SVN r32724, dyson@ wrote: > Add better support for larger I/O clusters, including larger physical > I/O. The support is not mature yet, and some of the underlying implementation > needs help. However, support does exist for IDE devices now. an

Re: undefined symbol 'stat'

2017-06-03 Thread Jeffrey Bouquet
On Sat, 3 Jun 2017 19:32:02 -0400, Allan Jude wrote: > On 2017-06-03 19:28, Jeffrey Bouquet wrote: > > The latest pkg updates broke firefox here, which won't build [ patches > > fail to apply ] > > Also seamonkey, but building sqlite3 locally fixed that. > > > > [ not that I'd expect

Re: undefined symbol 'stat'

2017-06-03 Thread Allan Jude
On 2017-06-03 19:28, Jeffrey Bouquet wrote: > The latest pkg updates broke firefox here, which won't build [ patches > fail to apply ] > Also seamonkey, but building sqlite3 locally fixed that. > > [ not that I'd expect firefox to build anyway, not been that lucky > recently... ] > >

undefined symbol 'stat'

2017-06-03 Thread Jeffrey Bouquet
The latest pkg updates broke firefox here, which won't build [ patches fail to apply ] Also seamonkey, but building sqlite3 locally fixed that. [ not that I'd expect firefox to build anyway, not been that lucky recently... ] Web search turns up no 'undefined symbol stat' on 12.0-CUR

Re: nvidia drivers mutex lock

2017-06-03 Thread Jeffrey Bouquet
SOME LINES BOTTOM POSTED, SEE... On Fri, 6/2/17, Tomoaki AOKI wrote: Subject: Re: nvidia drivers mutex lock To: freebsd-current@freebsd.org Cc: "Jeffrey Bouquet" , "blubee blubeeme" Date: Friday, June 2, 2017, 11:25 PM Hi. Version 381.22 (5

Re: NFS client perf. degradation when SCHED_ULE is used (was when SMP enabled)

2017-06-03 Thread Rick Macklem
Colin Percival wrote: >On 05/28/17 13:16, Rick Macklem wrote: >> cperciva@ is running a highly parallelized buuildworld and he sees better >> slightly better elapsed times and much lower system CPU for SCHED_ULE. >> >> As such, I suspect it is the single threaded, processes mostly sleeping >> wait

Re: NFS client perf. degradation when SCHED_ULE is used (was when SMP enabled)

2017-06-03 Thread Colin Percival
On 05/28/17 13:16, Rick Macklem wrote: > cperciva@ is running a highly parallelized buuildworld and he sees better > slightly better elapsed times and much lower system CPU for SCHED_ULE. > > As such, I suspect it is the single threaded, processes mostly sleeping > waiting > for I/O case that is

Re: nvidia drivers mutex lock

2017-06-03 Thread Tomoaki AOKI
Hi. Version 381.22 (5 days newer than 375.66) of the driver states... [1] Fixed hangs and crashes that could occur when an OpenGL context is created while the system is out of available memory. Can this be related with your hang? IMHO, possibly allocating new resource (using os.lock_mtx guard)