Date: Sun, 03 Oct 2004 14:42:17 -0400 From: Stephan Uphoff <ups@tree.com> To: Julian Elischer <julian@elischer.org> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: scheduler (sched_4bsd) questions Message-ID: <1096828937.38592.52.camel@palm.tree.com> In-Reply-To: <415FA496.6000902@elischer.org> References: <1096489576.3733.1868.camel@palm.tree.com> <200409291652.29990.jhb@FreeBSD.org> <1096496057.3733.2163.camel@palm.tree.com> <1096603981.21577.195.camel@palm.tree.com> <1096608201.21577.203.camel@palm.tree.com> <20041001141040.GA1556@peter.osted.lan> <1096647194.27811.12.camel@palm.tree.com> <20041001192551.GA3381@peter.osted.lan> <415EEFFE.5080309@elischer.org> <20041002183120.GA1202@peter.osted.lan> <415FA496.6000902@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2004-10-03 at 03:04, Julian Elischer wrote: > Hi stephan. > > Just reading your patch(es).. > > What's the logic behind adding the critical sections around the > priority changes in the turnstyle code? > > can you give an example of the timeline you are avoidning? > I presume it involves an interrupt setting another thread running. John asked the same question - the answer should already be in your inbox ;-) ( Re: scheduler (sched_4bsd) questions | Wed, 29 Sep 2004 18:14:17 -0400) > > Why do you think that it is unacceptible to allow a thread with a lower > priority to continue to run on another cpu (or this cpu) (maybe_preempt_in_ksegrp()) > Can you show the reason that this is "critical" and not just suboptimal? > If you are going to preempt threads from the same KSEGRP why not preempt > threads from other ksegrps? BTW an available slot count going > -ve might not be a disaster.. it's just a count.. This may preempt other ksegrps once the thread gets a slot and adds itself to the right runtime queue. I kind of liked the idea of being able to limit the concurrency and decided to honor slot count. Normal cases will have as many slot openings as cpus and we can just preempt the current cpu. (if necessary) maybe_preempt_in_ksegrp is in general needed to allow priority inheritance to work correctly: Example: A ksegrp has two threads A and B. A owns mutex x. B owns mutex y and is blocked on mutex x. The clock thread C is blocked on mutex y held by B. C donates the priority to B and A. Thread A runs and releases x. Without maybe_preempt_in_ksegrp B does not get a slot and won't be added to the system run queue. Thread A exits the kernel and continues to run in userspace. C is still blocked (and maybe other interrupt threads) and A can potentially loop in userspace forever. ( Or until Peter sends a ping ;-) > I guess you must have KSEG_PEEMPT_BEST_CPU always set because > preempting the "not best" cpu would lead to teh same inversion problem > that you are trying to avoid, when you leave a thread running on another CPU > that has less priority (numerically greater than) than the one that you > are preempting.. Actually I don't have KSEG_PEEMPT_BEST_CPU defined. I just had the feeling that it will reduce switching when/once FULL_PREEMTION is defined. > > Where is the critical_enter that matches the extra critical_exit() > you put in sched_switch()? I haven' been able to yet figure out how > you don't get a double exit. but I've only looked for a few minutes. sched_switch calls setrunqueue() or slot_fill(). Both can call sched_add. sched_add can call maybe_preempt. maybe_preempt may call mi_switch without the extra critical_enter. > regarding the ksegrp runq. > For some time I have wanted to split it into 3 queues and the > threads will move between them. (in the ksegrp sched-private section) > queue 1.. threads that are running > queue 2.. threads that are on the system run queue. > queue 3.. threads that do not yet have a slot. > > what do you think? > > it should simplify the slot counting stuff. > This would be neat. Queue 3 needs to be sorted..... ... what is the maximum size of this queue ? Stephan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1096828937.38592.52.camel>