Date: Wed, 08 Sep 2004 01:13:05 -0700 From: Julian Elischer <julian@elischer.org> To: Jeff Roberson <jroberson@chesapeake.net> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/alpha/conf GENERIC src/sys/amd64/confGENERIC src/sys/sparc64/conf GENERIC Message-ID: <413EBF11.9030409@elischer.org> In-Reply-To: <20040908031300.T26496@mail.chesapeake.net> References: <200409072237.i87MbiL9044294@repoman.freebsd.org> <20040908024335.T26496@mail.chesapeake.net> <413EAC0B.4050906@samsco.org> <20040908031300.T26496@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Jeff Roberson wrote: > On Wed, 8 Sep 2004, Scott Long wrote: > > >>Jeff Roberson wrote: >> >>>What's not working well enough with ULE to run with it? >>> >> >>The package build machines were switched over to 4BSD not long ago and >>have since been reported to be more stable. I can also lock up or panic >>my test machine within seconds with ULE, especially if preemption is >>enabled. This was the case both before and after Julian's scheduler >>cleanup change went in, also. > > > I wasn't aware there were any more panics after julian's preemption > change. Are there any problems without preemption? What causes the panic > with preemption? There appear to be two problems. One that is still related to preemption and one that is not. the preemption problem is hard to describe, but seems to result in either a null reference of some kind (last I looked) and the one that is not driven by preemption finds that a kse is already in a run queue and panics.. The preemption one seems to be with KSE threads still but may not always be so. From your perspective the changes to ULE that I have made are: * Every thread always has a kse, and it is the same thing as the td_sched structure. * Concurrency/fairness (slightly overloaded but that may change some time) is no longer done with the number of KSEs avaliable but rather, with a plain counter of "threads on teh run queue or running" in the ksegrp. Some fields in the kse have moved into teh kg_sched struct. (with macros keeping the old name. * In addition.. setrunqueue has grown a flag argument that can say where we were called from so that the "preemptive" flag you have can be generated. The flag values are not set in concrete yet. Given these changes it would be a real help if you looked through the combined sched_ule.c/kern_switch.c to see if they or preemption is breaking any of your assumptions, published or otherwise. > > >>Scott >>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?413EBF11.9030409>