Re: Time to increase MAXPHYS?
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: >> >>> 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. >> >> and increased MAXPHYS from 64 kB to 128 kB. Is it time to increase it >> >> again, >> >> or do we need to wait at least two decades between changes? >> >> >> >> This is hurting performance on some systems; in particular, EC2 "io1" >> >> disks >> >> are optimized for 256 kB I/Os, EC2 "st1" (throughput optimized >> >> spinning rust) >> >> disks are optimized for 1 MB I/Os, and Amazon's NFS service (EFS) >> >> recommends >> >> using a maximum I/O size of 1 MB (and despite NFS not being *physical* >> >> I/O it >> >> seems to still be limited by MAXPHYS). >> >> >> > We increase it in freebsd 8 and 10.3 on our systems, Only good results. >> > >> > sys/sys/param.h:#define MAXPHYS (1024 * 1024) /* max raw I/O >> > transfer size */ >> > >> > ___ >> > freebsd-current@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current >> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@f >> reebsd.org" >> >> At some point Warner and I discussed how hard it might be to make this a >> boot time tunable, so that big amd64 machines can have a larger value >> without causing problems for smaller machines. >> >> ZFS supports a block size of 1mb, and doing I/Os in 128kb negates some >> of the benefit. >> >> I am preparing some benchmarks and other data along with a patch to >> increase the maximum size of pipe I/O's as well, because using 1MB >> offers a relatively large performance gain there as well. >> > > It doesn't look to be hard to change this, though struct buf depends on > MAXPHYS: > struct vm_page *b_pages[btoc(MAXPHYS)]; > and b_pages isn't the last item in the list, so changing MAXPHYS at boot > time would cause an ABI change. IMHO, we should move it to the last element > so that wouldn't happen. IIRC all buf allocations are from a fixed pool. > We'd have to audit anybody that creates one on the stack knowing it will be > persisted. Given how things work, I don't think this is possible, so we may > be safe. Thankfully, struct bio doesn't seem to be affected. > > As for making it boot-time configurable, it shouldn't be too horrible with > the above change. We should have enough of the tunables mechanism up early > enough to pull this in before we create the buf pool. > > Netflix runs MAXPHYS of 8MB. There's issues with something this big, to be > sure, especially on memory limited systems. Lots of hardware can't do this > big an I/O, and some drivers can't cope, even if the underlying hardware > can. Since we don't use such drivers at work, I don't have a list handy > (though I think the SG list for NVMe limits it to 1MB). 128k is totally > reasonable bump by default, but I think going larger by default should be > approached with some caution given the overhead that adds to struct buf. > Having it be a run-time tunable would be great. > Of course 128k is reasonable, it's the current default :). I'd mean to say that doubling would have a limited impact. 1MB might be a good default, but it might be too big for smaller systems (nothing says it has to be a MI constant, though). It would be a perfectly fine default if it were a tunable. > There's a number of places in userland that depend on MAXPHYS, which is > unfortunate since they assume a fixed value and don't pick it up from the > kernel or kernel config. Thankfully, there are only a limited number of > these. > There's a number of other places that assume MAXPHYS is constant. The ahci driver uses it to define the max number of SG operations you can have, for example. aio has an array sized based off of it. There are some places that use this when they should use 128k instead. There's several places that use it to define other constants, and it would take a while to run them all to ground to make sure they are all good. We might need to bump DFLTPHYS as well, so it might also make a good tunable. There's a few places that check things in terms of a fixed multiple of MAXPHYS that are rules of thumb that kinda work today maybe by accident or maybe the 100 * MAXPHYS is highly scientific. It's hard to say without careful study. For example, until recently, nvmecontrol would use MAXPHYS. But it's the system default MAXPHYS. And even if it isn't, there's currently a hard limit of 1MB for an I/O imposed by how the driver uses nvme's SG lists. But it doesn't show up as MAXPHYS, but rather as NVME_MAX_XFER_SIZE in places. It totally su
Re: Time to increase MAXPHYS?
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 > > needs help. However, support does exist for IDE devices now. > > and increased MAXPHYS from 64 kB to 128 kB. Is it time to increase it > again, > or do we need to wait at least two decades between changes? > > This is hurting performance on some systems; in particular, EC2 "io1" disks > are optimized for 256 kB I/Os, EC2 "st1" (throughput optimized spinning > rust) > disks are optimized for 1 MB I/Os, and Amazon's NFS service (EFS) > recommends > using a maximum I/O size of 1 MB (and despite NFS not being *physical* I/O > it > seems to still be limited by MAXPHYS). > MAXPHYS is the largest I/O transaction you can push through the system. It doesn't matter that the I/O is physical or not. The name is a relic from a time that NFS didn't exist. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time to increase MAXPHYS?
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 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. > >> and increased MAXPHYS from 64 kB to 128 kB. Is it time to increase it > >> again, > >> or do we need to wait at least two decades between changes? > >> > >> This is hurting performance on some systems; in particular, EC2 "io1" > >> disks > >> are optimized for 256 kB I/Os, EC2 "st1" (throughput optimized > >> spinning rust) > >> disks are optimized for 1 MB I/Os, and Amazon's NFS service (EFS) > >> recommends > >> using a maximum I/O size of 1 MB (and despite NFS not being *physical* > >> I/O it > >> seems to still be limited by MAXPHYS). > >> > > We increase it in freebsd 8 and 10.3 on our systems, Only good results. > > > > sys/sys/param.h:#define MAXPHYS (1024 * 1024) /* max raw I/O > > transfer size */ > > > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > freebsd.org" > > At some point Warner and I discussed how hard it might be to make this a > boot time tunable, so that big amd64 machines can have a larger value > without causing problems for smaller machines. > > ZFS supports a block size of 1mb, and doing I/Os in 128kb negates some > of the benefit. > > I am preparing some benchmarks and other data along with a patch to > increase the maximum size of pipe I/O's as well, because using 1MB > offers a relatively large performance gain there as well. > It doesn't look to be hard to change this, though struct buf depends on MAXPHYS: struct vm_page *b_pages[btoc(MAXPHYS)]; and b_pages isn't the last item in the list, so changing MAXPHYS at boot time would cause an ABI change. IMHO, we should move it to the last element so that wouldn't happen. IIRC all buf allocations are from a fixed pool. We'd have to audit anybody that creates one on the stack knowing it will be persisted. Given how things work, I don't think this is possible, so we may be safe. Thankfully, struct bio doesn't seem to be affected. As for making it boot-time configurable, it shouldn't be too horrible with the above change. We should have enough of the tunables mechanism up early enough to pull this in before we create the buf pool. Netflix runs MAXPHYS of 8MB. There's issues with something this big, to be sure, especially on memory limited systems. Lots of hardware can't do this big an I/O, and some drivers can't cope, even if the underlying hardware can. Since we don't use such drivers at work, I don't have a list handy (though I think the SG list for NVMe limits it to 1MB). 128k is totally reasonable bump by default, but I think going larger by default should be approached with some caution given the overhead that adds to struct buf. Having it be a run-time tunable would be great. There's a number of places in userland that depend on MAXPHYS, which is unfortunate since they assume a fixed value and don't pick it up from the kernel or kernel config. Thankfully, there are only a limited number of these. Of course, there's times when I/Os can return much more than this. Reading drive log pages, for example, can generate tens or hundreds of MB of data, and there's no way to do that with one transaction today. If drive makers were perfect, we could use the generally defined offset and length fields to read them out piecemeal. If the log is table, a big if for some of the snapshots of internal state logs that are sometimes necessary to investigate problems... It sure would be nice if there were a way to have super-huge I/O on an exception basis for these situations. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time to increase MAXPHYS?
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 the underlying >>> implementation >>> needs help. However, support does exist for IDE devices now. >> and increased MAXPHYS from 64 kB to 128 kB. Is it time to increase it >> again, >> or do we need to wait at least two decades between changes? >> >> This is hurting performance on some systems; in particular, EC2 "io1" >> disks >> are optimized for 256 kB I/Os, EC2 "st1" (throughput optimized >> spinning rust) >> disks are optimized for 1 MB I/Os, and Amazon's NFS service (EFS) >> recommends >> using a maximum I/O size of 1 MB (and despite NFS not being *physical* >> I/O it >> seems to still be limited by MAXPHYS). >> > We increase it in freebsd 8 and 10.3 on our systems, Only good results. > > sys/sys/param.h:#define MAXPHYS (1024 * 1024) /* max raw I/O > transfer size */ > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" At some point Warner and I discussed how hard it might be to make this a boot time tunable, so that big amd64 machines can have a larger value without causing problems for smaller machines. ZFS supports a block size of 1mb, and doing I/Os in 128kb negates some of the benefit. I am preparing some benchmarks and other data along with a patch to increase the maximum size of pipe I/O's as well, because using 1MB offers a relatively large performance gain there as well. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Time to increase MAXPHYS?
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, support does exist for IDE devices now. and increased MAXPHYS from 64 kB to 128 kB. Is it time to increase it again, or do we need to wait at least two decades between changes? This is hurting performance on some systems; in particular, EC2 "io1" disks are optimized for 256 kB I/Os, EC2 "st1" (throughput optimized spinning rust) disks are optimized for 1 MB I/Os, and Amazon's NFS service (EFS) recommends using a maximum I/O size of 1 MB (and despite NFS not being *physical* I/O it seems to still be limited by MAXPHYS). We increase it in freebsd 8 and 10.3 on our systems, Only good results. sys/sys/param.h:#define MAXPHYS (1024 * 1024) /* max raw I/O transfer size */ ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Time to increase MAXPHYS?
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. and increased MAXPHYS from 64 kB to 128 kB. Is it time to increase it again, or do we need to wait at least two decades between changes? This is hurting performance on some systems; in particular, EC2 "io1" disks are optimized for 256 kB I/Os, EC2 "st1" (throughput optimized spinning rust) disks are optimized for 1 MB I/Os, and Amazon's NFS service (EFS) recommends using a maximum I/O size of 1 MB (and despite NFS not being *physical* I/O it seems to still be limited by MAXPHYS). -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: undefined symbol 'stat'
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 firefox to build anyway, not been that lucky > > recently... ] > > > > Web search turns up no 'undefined symbol stat' on 12.0-CURRENT that I can > > find. > > > > Subject give the entirety of the error. > > Building webkit-gtk2 locally as of now to try to fix it in a third round > > of ports. ... > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > > > The ino64 change that went into -current recently changed a lot of stuff > related to stat(), and versioned the symbol. You are trying to run apps > compiled for a newer version of -current than you are running. You need > to update your kernel and userland to patch what pkg is built against. > > -- > Allan Jude Thanks. I'm getting around to it, unfortunately too slowly. Not a half hour after the email, I have the v11 firefox package running happily. webkit-gtk2 also built here. So no immediate concern, browser or other GUI [ claws-mail ] at least that I use daily. [ pkg.freebsd.org seems way undermentioned in the wiki, and elsewhere... BTW ] ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: undefined symbol 'stat'
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... ] > > Web search turns up no 'undefined symbol stat' on 12.0-CURRENT that I can > find. > > Subject give the entirety of the error. > Building webkit-gtk2 locally as of now to try to fix it in a third round of > ports. ... > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > The ino64 change that went into -current recently changed a lot of stuff related to stat(), and versioned the symbol. You are trying to run apps compiled for a newer version of -current than you are running. You need to update your kernel and userland to patch what pkg is built against. -- Allan Jude signature.asc Description: OpenPGP digital signature
undefined symbol 'stat'
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-CURRENT that I can find. Subject give the entirety of the error. Building webkit-gtk2 locally as of now to try to fix it in a third round of ports. ... ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: nvidia drivers mutex lock
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 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) without checking the lock first while previous request is waiting for another can cause the duplicated lock situation. And high memory pressure would easily cause the situation. [1] http://www.nvidia.com/Download/driverResults.aspx/118527/en-us Hope it helps. On Thu, 1 Jun 2017 22:35:46 + (UTC) Jeffrey Bouquet wrote: > I see the same message, upon load, ... > > On Thu, 6/1/17, blubee blubeeme wrote: > > Subject: nvidia drivers mutex lock > To: freebsd-po...@freebsd.org, freebsd-current@freebsd.org > Date: Thursday, June 1, 2017, 11:35 AM > > I'm running nvidia-drivers 375.66 with a GTX > 1070 on FreeBSD-Current > > This problem just started happening > recently but, every so often my laptop > screen will just blank out and then I > have to power cycle to get the > machine up and running again. > > It seems to be a problem with nvidia > drivers acquiring duplicate lock. Any > info on this? > > Jun〓 2 02:29:41 blubee kernel: > acquiring duplicate lock of same type: > "os.lock_mtx" > Jun〓 2 02:29:41 blubee kernel: 1st > os.lock_mtx @ nvidia_os.c:841 > Jun〓 2 02:29:41 blubee kernel: 2nd > os.lock_mtx @ nvidia_os.c:841 > Jun〓 2 02:29:41 blubee kernel: > stack backtrace: > Jun〓 2 02:29:41 blubee kernel: #0 > 0x80ab7770 at > witness_debugger+0x70 > Jun〓 2 02:29:41 blubee kernel: #1 > 0x80ab7663 at > witness_checkorder+0xe23 > Jun〓 2 02:29:41 blubee kernel: #2 > 0x80a35b93 at > __mtx_lock_flags+0x93 > Jun〓 2 02:29:41 blubee kernel: #3 > 0x82f4397b at > os_acquire_spinlock+0x1b > Jun〓 2 02:29:41 blubee kernel: #4 > 0x82c48b15 at _nv012002rm+0x185 > Jun〓 2 02:29:41 blubee kernel: > ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: > Argument #4 type mismatch - Found > [Buffer], ACPI requires [Package] > (20170303/nsarguments-205) > Jun〓 2 02:29:42 blubee kernel: > nvidia-modeset: Allocated GPU:0 > (GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @ > PCI::01:00.0 > > Best, > Owen > ___ > freebsd-po...@freebsd.org > mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > > > > ... then Xorg will run happily twelve hours or so. The lockups here happen usually > when too large or too many of number of tabs/ large web pages with complex CSS etc > are opened at a time. > So no help, just a 'me too'. > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > -- Tomoaki AOKI might be a workaround Xorg/nvidia ran all night with this: nvidia-settings >> X server display configuration >> Advanced >> Force Full Composition Pipeline ... for the laptop freezing. Could not hurt to try. " merge with Xorg.conf " from nvidia-settings... .. 18 hours uptime so far, even past the 3 am periodic scripts. Have not rebooted out of the Xorg though so may require edit-out of xorg.conf if that is the case, in other words differing from real-time apply and xorg initially start applies. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NFS client perf. degradation when SCHED_ULE is used (was when SMP enabled)
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 >> waiting >> for I/O case that is broken. >> I suspect this is how many people use NFS, since a highly parallelized make >> would >> not be a typical NFS client task, I think? > >Running `make buildworld -j36` on an EC2 "c4.8xlarge" instance (36 vCPUs, 60 >GB RAM, 10 GbE) with GENERIC-NODEBUG, ULE has a slight edge over 4BSD: > >GENERIC-NODEBUG, SCHED_4BSD: >1h14m12.48s real6h25m44.59s user1h4m53.42s sys >1h15m25.48s real6h25m12.20s user1h4m34.23s sys >1h13m34.02s real6h25m14.44s user1h4m09.55s sys >1h13m44.04s real6h25m08.60s user1h4m40.21s sys >1h14m59.69s real6h25m53.13s user1h4m55.20s sys >1h14m24.00s real6h24m59.29s user1h5m37.31s sys > >GENERIC-NODEBUG, SCHED_ULE: > 1h13m00.61s real6h02m47.59s user26m45.89s sys >1h12m30.18s real6h01m39.97s user26m16.45s sys >1h13m08.43s real6h01m46.94s user26m39.20s sys >1h12m18.94s real6h02m26.80s user27m39.71s sys >1h13m21.38s real6h00m46.13s user27m14.96s sys >1h12m01.80s real6h02m24.48s user27m18.37s sys > >Running `make buildworld -j2` on an E2 "m4.large" instance (2 vCPUs, 8 GB RAM, >~ 500 Mbps network), 4BSD has a slight edge over ULE on real and sys >time but is slightly worse on user time: > >GENERIC-NODEBUG, SCHED_4BSD: >6h29m25.17s real7h2m56.02s user 14m52.63s sys >6h29m36.82s real7h2m58.19s user 15m14.21s sys >6h28m27.61s real7h1m38.24s user 14m56.91s sys >6h27m05.42s real7h1m38.57s user 15m04.31s sys > >GENERIC-NODEBUG, SCHED_ULE: > 6h34m19.41s real6h59m43.99s user18m8.62s sys >6h33m55.08s real6h58m44.91s user18m4.31s sys >6h34m49.68s real6h56m03.58s user17m49.83s sys >6h35m22.14s real6h58m12.62s user17m52.05s sys Doing these test runs, but on the 36v CPU system would be closer to what I was testing. My tests do not use "-j" and run on an 8core chunk of real hardware. >Note that in both cases there is lots of idle time (although far more in the >-j36 case); this is partly due to a lack of parallelism in buildworld, but >largely due to having /usr/obj mounted on Amazon EFS. > >These differences all seem within the range which could result from cache >effects due to threads staying on one CPU rather than bouncing around; so >whatever Rick is tripping over, it doesn't seem to be affecting these tests. Yep. Thanks for doing the testing, rick ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: NFS client perf. degradation when SCHED_ULE is used (was when SMP enabled)
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 broken. > I suspect this is how many people use NFS, since a highly parallelized make > would > not be a typical NFS client task, I think? Running `make buildworld -j36` on an EC2 "c4.8xlarge" instance (36 vCPUs, 60 GB RAM, 10 GbE) with GENERIC-NODEBUG, ULE has a slight edge over 4BSD: GENERIC-NODEBUG, SCHED_4BSD: 1h14m12.48s real6h25m44.59s user1h4m53.42s sys 1h15m25.48s real6h25m12.20s user1h4m34.23s sys 1h13m34.02s real6h25m14.44s user1h4m09.55s sys 1h13m44.04s real6h25m08.60s user1h4m40.21s sys 1h14m59.69s real6h25m53.13s user1h4m55.20s sys 1h14m24.00s real6h24m59.29s user1h5m37.31s sys GENERIC-NODEBUG, SCHED_ULE: 1h13m00.61s real6h02m47.59s user26m45.89s sys 1h12m30.18s real6h01m39.97s user26m16.45s sys 1h13m08.43s real6h01m46.94s user26m39.20s sys 1h12m18.94s real6h02m26.80s user27m39.71s sys 1h13m21.38s real6h00m46.13s user27m14.96s sys 1h12m01.80s real6h02m24.48s user27m18.37s sys Running `make buildworld -j2` on an E2 "m4.large" instance (2 vCPUs, 8 GB RAM, ~ 500 Mbps network), 4BSD has a slight edge over ULE on real and sys time but is slightly worse on user time: GENERIC-NODEBUG, SCHED_4BSD: 6h29m25.17s real7h2m56.02s user 14m52.63s sys 6h29m36.82s real7h2m58.19s user 15m14.21s sys 6h28m27.61s real7h1m38.24s user 14m56.91s sys 6h27m05.42s real7h1m38.57s user 15m04.31s sys GENERIC-NODEBUG, SCHED_ULE: 6h34m19.41s real6h59m43.99s user18m8.62s sys 6h33m55.08s real6h58m44.91s user18m4.31s sys 6h34m49.68s real6h56m03.58s user17m49.83s sys 6h35m22.14s real6h58m12.62s user17m52.05s sys Note that in both cases there is lots of idle time (although far more in the -j36 case); this is partly due to a lack of parallelism in buildworld, but largely due to having /usr/obj mounted on Amazon EFS. These differences all seem within the range which could result from cache effects due to threads staying on one CPU rather than bouncing around; so whatever Rick is tripping over, it doesn't seem to be affecting these tests. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: nvidia drivers mutex lock
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) without checking the lock first while previous request is waiting for another can cause the duplicated lock situation. And high memory pressure would easily cause the situation. [1] http://www.nvidia.com/Download/driverResults.aspx/118527/en-us Hope it helps. On Thu, 1 Jun 2017 22:35:46 + (UTC) Jeffrey Bouquet wrote: > I see the same message, upon load, ... > > On Thu, 6/1/17, blubee blubeeme wrote: > > Subject: nvidia drivers mutex lock > To: freebsd-po...@freebsd.org, freebsd-current@freebsd.org > Date: Thursday, June 1, 2017, 11:35 AM > > I'm running nvidia-drivers 375.66 with a GTX > 1070 on FreeBSD-Current > > This problem just started happening > recently but, every so often my laptop > screen will just blank out and then I > have to power cycle to get the > machine up and running again. > > It seems to be a problem with nvidia > drivers acquiring duplicate lock. Any > info on this? > > Jun〓 2 02:29:41 blubee kernel: > acquiring duplicate lock of same type: > "os.lock_mtx" > Jun〓 2 02:29:41 blubee kernel: 1st > os.lock_mtx @ nvidia_os.c:841 > Jun〓 2 02:29:41 blubee kernel: 2nd > os.lock_mtx @ nvidia_os.c:841 > Jun〓 2 02:29:41 blubee kernel: > stack backtrace: > Jun〓 2 02:29:41 blubee kernel: #0 > 0x80ab7770 at > witness_debugger+0x70 > Jun〓 2 02:29:41 blubee kernel: #1 > 0x80ab7663 at > witness_checkorder+0xe23 > Jun〓 2 02:29:41 blubee kernel: #2 > 0x80a35b93 at > __mtx_lock_flags+0x93 > Jun〓 2 02:29:41 blubee kernel: #3 > 0x82f4397b at > os_acquire_spinlock+0x1b > Jun〓 2 02:29:41 blubee kernel: #4 > 0x82c48b15 at _nv012002rm+0x185 > Jun〓 2 02:29:41 blubee kernel: > ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: > Argument #4 type mismatch - Found > [Buffer], ACPI requires [Package] > (20170303/nsarguments-205) > Jun〓 2 02:29:42 blubee kernel: > nvidia-modeset: Allocated GPU:0 > (GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @ > PCI::01:00.0 > > Best, > Owen > ___ > freebsd-po...@freebsd.org > mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > > > > ... then Xorg will run happily twelve hours or so. The lockups here happen > usually > when too large or too many of number of tabs/ large web pages with complex > CSS etc > are opened at a time. > So no help, just a 'me too'. > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > -- Tomoaki AOKI ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
