Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311

2020-05-13 Thread Justin Hibbits
Hi Mark, On Wed, 13 May 2020 01:43:23 -0700 Mark Millard wrote: > [I'm adding a reference to an old arm64/aarch64 bug that had > pages turning to zero, in case this 32-bit powerpc issue is > somewhat analogous.] > > On 2020-May-13, at 00:29, Mark Millard wrote: > > > [stress alone is

Re: zfs deadlock on r360452 relating to busy vm page

2020-05-13 Thread Mark Johnston
On Wed, May 13, 2020 at 10:45:24AM +0300, Andriy Gapon wrote: > On 13/05/2020 10:35, Andriy Gapon wrote: > > On 13/05/2020 01:47, Bryan Drewery wrote: > >> Trivial repro: > >> > >> dd if=/dev/zero of=blah & tail -F blah > >> ^C > >> load: 0.21 cmd: tail 72381 [prev->lr_read_cv] 2.17r 0.00u 0.01s

Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311

2020-05-13 Thread Mark Millard
[I'm adding a reference to an old arm64/aarch64 bug that had pages turning to zero, in case this 32-bit powerpc issue is somewhat analogous.] On 2020-May-13, at 00:29, Mark Millard wrote: > [stress alone is sufficient to have jemalloc asserts fail > in stress, no need for a multi-socket G4

Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311

2020-05-13 Thread Mark Millard
[stress alone is sufficient to have jemalloc asserts fail in stress, no need for a multi-socket G4 either. No need to involve nfsd, mountd, rpcbind or the like. This is not a claim that I know all the problems to be the same, just that a jemalloc reported failure in this simpler context happens

Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311

2020-05-13 Thread Mark Millard
[Yet another new kind of experiment. But this looks like I can cause problems in fairly sort order on demand now. Finally! And with that I've much better evidence for kernel vs. user-space process for making the zeroed memory appear in, for example, nfsd.] I've managed to get: :

Re: zfs deadlock on r360452 relating to busy vm page

2020-05-13 Thread Andriy Gapon
On 13/05/2020 10:35, Andriy Gapon wrote: > On 13/05/2020 01:47, Bryan Drewery wrote: >> Trivial repro: >> >> dd if=/dev/zero of=blah & tail -F blah >> ^C >> load: 0.21 cmd: tail 72381 [prev->lr_read_cv] 2.17r 0.00u 0.01s 0% 2600k >> #0 0x80bce615 at mi_switch+0x155 >> #1

Re: zfs deadlock on r360452 relating to busy vm page

2020-05-13 Thread Andriy Gapon
On 13/05/2020 01:47, Bryan Drewery wrote: > Trivial repro: > > dd if=/dev/zero of=blah & tail -F blah > ^C > load: 0.21 cmd: tail 72381 [prev->lr_read_cv] 2.17r 0.00u 0.01s 0% 2600k > #0 0x80bce615 at mi_switch+0x155 > #1 0x80c1cfea at sleepq_switch+0x11a > #2 0x80b57f0a

lkpi: print stack trace in WARN_ON ?

2020-05-13 Thread Andriy Gapon
Just to get a bigger exposure: https://reviews.freebsd.org/D24779 I think that this is a good idea and, if I am not mistaken, it should match the Linux behavior. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list