Date: Thu, 30 Nov 2017 23:16:31 +0100 From: "Hartmann, O." <ohartmann@walstatt.org> To: Hans Petter Selasky <hselasky@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r326376 - head/sys/kern Message-ID: <20171130231627.2eecc273@hermann> In-Reply-To: <201711292328.vATNSeOM046518@repo.freebsd.org> References: <201711292328.vATNSeOM046518@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 29 Nov 2017 23:28:40 +0000 (UTC) Hans Petter Selasky <hselasky@FreeBSD.org> wrote: > Author: hselasky > Date: Wed Nov 29 23:28:40 2017 > New Revision: 326376 > URL: https://svnweb.freebsd.org/changeset/base/326376 > > Log: > The sched_add() function is not only used when the thread is > initially started, but also by the turnstiles to mark a thread as > runnable for all locks, for instance sleepqueues do: > setrunnable()->sched_wakeup()->sched_add() > > In r326218 code was added to allow booting from non-zero CPU numbers > by setting the ts_cpu field inside the ULE scheduler's sched_add() > function. This had an undesired side-effect that prior sched_pin() > and sched_bind() calls got disregarded. This patch fixes the > initialization of the ts_cpu field for the ULE scheduler to only > happen once when the initial thread is constructed during system > init. Forking will then later on ensure that a valid ts_cpu value > gets copied to all children. > > Reviewed by: jhb, kib > Discussed with: nwhitehorn > MFC after: 1 month > Differential revision: https://reviews.freebsd.org/D13298 > Sponsored by: Mellanox Technologies > > Modified: > head/sys/kern/sched_ule.c > > Modified: head/sys/kern/sched_ule.c > ============================================================================== > --- head/sys/kern/sched_ule.c Wed Nov 29 21:16:14 2017 > (r326375) +++ head/sys/kern/sched_ule.c Wed Nov 29 23:28:40 > 2017 (r326376) @@ -1405,7 +1405,6 @@ sched_setup(void *dummy) > > /* Add thread0's load since it's running. */ > TDQ_LOCK(tdq); > - td_get_sched(&thread0)->ts_cpu = curcpu; /* Something valid > to start */ thread0.td_lock = TDQ_LOCKPTR(TDQ_SELF()); > tdq_load_add(tdq, &thread0); > tdq->tdq_lowpri = thread0.td_priority; > @@ -1642,6 +1641,7 @@ schedinit(void) > ts0->ts_ltick = ticks; > ts0->ts_ftick = ticks; > ts0->ts_slice = 0; > + ts0->ts_cpu = curcpu; /* set valid CPU number */ > } > > /* > @@ -2453,7 +2453,6 @@ sched_add(struct thread *td, int flags) > * Pick the destination cpu and if it isn't ours transfer to > the > * target cpu. > */ > - td_get_sched(td)->ts_cpu = curcpu; /* Pick something valid > to start */ cpu = sched_pickcpu(td, flags); > tdq = sched_setcpu(td, cpu, flags); > tdq_add(tdq, td, flags); > _______________________________________________ > svn-src-head@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/svn-src-head > To unsubscribe, send any mail to > "svn-src-head-unsubscribe@freebsd.org" The patch doesn't solve problems for me when either tmpfs is used as a loaded kernel module or compiled into the kernel and the filesystem contains mount points comprised from tempfs, like /tmp or /var/run. Any kernel with tmpfs compiled in seems to crash, any kernel, including GENERIC, seems also to crash when any tempfs is involved. After nearly two days I managed to boot one box again, figuring that tempfs triggers a kernel panic. oh
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171130231627.2eecc273>