Date: Sun, 03 Oct 2004 00:04:54 -0700 From: Julian Elischer <julian@elischer.org> To: Stephan Uphoff <ups@tree.com> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: scheduler (sched_4bsd) questions Message-ID: <415FA496.6000902@elischer.org> In-Reply-To: <1096760257.34527.14.camel@palm.tree.com> 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> <20041002053351.GA6259@peter.osted.lan> <415EEFFE.5080309@elischer.org> <20041002183120.GA1202@peter.osted.lan> <1096760257.34527.14.camel@palm.tree.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Stephan Uphoff wrote: > On Sat, 2004-10-02 at 14:31, Peter Holm wrote: > >>OK, right now I'm testing with all of Stephan's patches + the >>MUTEX_WAKE_ALL flag. Uptime is 3 3/4 hour and looking good. > > > Great. > > Your attached diff contained all the fixes needed and I don't see the > need to post a cumulative patch. > > The only thing left to do is migrate a critical sections from > kern_mutex.c to subr_turnstile.c for readability. > (no functional changes) > > Maybe it would also better to just force MUTEX_WAKE_ALL in > kern_mutex.c (#ifndef MUTEX_WAKE_ALL \n#define MUTEX_WAKE_ALL\n#endif) > to avoid temporary configuration file pollution? > > Stephan > > 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. 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.. 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.. 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. 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?415FA496.6000902>