[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/55402: amd64/9.99.68/9.99.68: xen/zfs - kernel: double fault trap, code=0
I can do that.
I do have the feeling that zfs code is very generous with stack. Also
scan has a recursive structure where I don't know the upper bound
of the recursion. This mini pool was just around 800GB. Every three
recursions we eat about 1k of stack.
We seem to be running pretty close to our kernel stack limit when
Maybe enlarging our kernel stack could also be an option.
Other systems seem to be able to handle normal zfs operations.
Will check for dsl_scan in original form anyway - takes some time though.
On 06/20/20 20:45, Jaromír Doleček wrote:
The following reply was made to PR kern/55402; it has been noted by GNATS.
From: =?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=?= <jaromir.dolecek%gmail.com@localhost>
To: "gnats-bugs%NetBSD.org@localhost" <gnats-bugs%netbsd.org@localhost>
Subject: Re: kern/55402: amd64/9.99.68/9.99.68: xen/zfs - kernel: double fault
Date: Sat, 20 Jun 2020 20:39:52 +0200
Can you confirm whether it's enough to apply just the change for
vdev_queue.c, i.e. can you try the scrum with dsl_scan.c same as in
repository (without patch)?
I'd prefer to keep dsl_scan.c closer to upstream unless absolutely
necessary to change.
Le sam. 20 juin 2020 =C3=A0 20:28, Frank Kardel <kardel%netbsd.org@localhost> a =C3=
> That did it - the scrub run now completed successfully.
> On 06/20/20 19:00, Jarom=C3=ADr Dole=C4=8Dek wrote:
> > The following reply was made to PR kern/55402; it has been noted by GNA=
> > From: =3D?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=3D?=3D <jaromir.dolecek@gmail=
> > To: "gnats-bugs%NetBSD.org@localhost" <gnats-bugs%netbsd.org@localhost>
> > Cc:
> > Subject: Re: kern/55402: amd64/9.99.68/9.99.68: xen/zfs - kernel: doubl=
> > trap, code=3D0
> > Date: Sat, 20 Jun 2020 18:55:28 +0200
> > Le sam. 20 juin 2020 =3DC3=3DA0 15:45, Frank Kardel <kardel%netbsd.or@localhost=
g> a =3DC3=3D
> > =3DA9crit :
> > > Well it goes a bit further but hits the double fault
> > >
> > > now with 57 frames (two > 1k) at about the same accumulated stack =
> > >
> > > Some space was saved by the patch, but presumably not enough.
> > OK, I've updated the patch. My previous change in
> > vdev_queue_io_to_issue() did not work, gcc returns the stack on the
> > end of the function, not when going out of the block.
> > New version reduced vdev_queue_io_to_issue() to use only 160 bytes of
> > stack instead of 1152, and dsl_scan_visitbp()+ dsl_scan_visitdnode()
> > pair now takes 40 less bytes.
> > Can you check if this is enough to get it through?
> > http://www.netbsd.org/~jdolecek/zfs_reduce_stack.diff
> > Jaromir
Main Index |
Thread Index |