Date: Mon, 30 Mar 2020 22:31:27 -0400 From: Mark Johnston <markj@freebsd.org> To: Li-Wen Hsu <lwhsu@freebsd.org> Cc: src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r359436 - in head/sys: kern net sys Message-ID: <20200331023127.GA97238@raichu> In-Reply-To: <20200331015905.GC65028@raichu> References: <202003301422.02UEMrxL059978@repo.freebsd.org> <CAKBkRUxrzmqkDrsPXLWr%2B5d6djghR1jbr_Lg5RpvpanAzOxtKw@mail.gmail.com> <20200331015905.GC65028@raichu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 30, 2020 at 09:59:05PM -0400, Mark Johnston wrote: > On Tue, Mar 31, 2020 at 09:40:51AM +0800, Li-Wen Hsu wrote: > > On Mon, Mar 30, 2020 at 10:32 PM Mark Johnston <markj@freebsd.org> wrote: > > > > > > Author: markj > > > Date: Mon Mar 30 14:22:52 2020 > > > New Revision: 359436 > > > URL: https://svnweb.freebsd.org/changeset/base/359436 > > > > > > Log: > > > Simplify taskqgroup inititialization. > > > > > > taskqgroup initialization was broken into two steps: > > > > > > 1. allocate the taskqgroup structure, at SI_SUB_TASKQ; > > > 2. initialize taskqueues, start taskqueue threads, enqueue "binder" > > > tasks to bind threads to specific CPUs, at SI_SUB_SMP. > > > > > > Step 2 tries to handle the case where tasks have already been attached > > > to a queue, by migrating them to their intended queue. In particular, > > > tasks can't be enqueued before step 2 has completed. This breaks NFS > > > mountroot on systems using an iflib-based driver when EARLY_AP_STARTUP > > > is not defined, since mountroot happens before SI_SUB_SMP in this case. > > > > > > Simplify initialization: do all initialization except for CPU binding at > > > SI_SUB_TASKQ. This means that until CPU binding is completed, group > > > tasks may be executed on a CPU other than that to which they were bound, > > > but this should not be a problem for existing users of the taskqgroup > > > KPIs. > > > > > > Reported by: sbruno > > > Tested by: bdragon, sbruno > > > MFC after: 1 month > > > Sponsored by: The FreeBSD Foundation > > > Differential Revision: https://reviews.freebsd.org/D24188 > > > > > > Modified: > > > head/sys/kern/subr_gtaskqueue.c > > > head/sys/net/iflib.c > > > head/sys/sys/gtaskqueue.h > > > > Hi Mark, > > > > I see many "panic: deadlres_td_sleep_q: possible deadlock detected" in > > the CI after this commit: > > > > https://ci.freebsd.org/job/FreeBSD-head-amd64-test/14738/consoleFull > > https://ci.freebsd.org/job/FreeBSD-head-amd64-test/14739/consoleFull > > https://ci.freebsd.org/job/FreeBSD-head-amd64-test/14741/consoleFull > > https://ci.freebsd.org/job/FreeBSD-head-amd64-test/14742/consoleFull > > https://ci.freebsd.org/job/FreeBSD-head-amd64-test/14743/console > > https://ci.freebsd.org/job/FreeBSD-head-amd64-test/14744/consoleFull > > > > It seems could be triggered by sys.netinet6.frag6.* > > sys.netpfil.common.* sbin.pfctl.pfctl_test.* tests, and there are lots > > of test cases timed out. > > > > Can you help check these? > > I see, it is actually caused by r359438. I'm looking at it now. I verified that the netpfil and netinet6 tests pass with r359477.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200331023127.GA97238>