Re: cvs commit: src/sys/kern sched_ule.c (fwd)

Tony Arcieri wrote:
> On Tue, Dec 14, 2004 at 05:08:43PM -0600, Jon Noack wrote:
>> I thought about trying this last night when I saw that ULE was
>> resurrected.  Make sure you also grab kern_sig.c:
>> http://lists.freebsd.org/pipermail/cvs-src/2004-December/036757.html
>>
>> I can't say whether those 3 files are all you need, just that I would
>> also include kern_sig.c... ;-)
>
> Rebuilt with kern_sig.c from -CURRENT, everything seems fine, as far as I
> can tell.  Are there really any substantial changes in kern_sig.c and
> kern_switch.c that would affect the stability of 5_STABLE (and does
> UMA in 5_STABLE ensure thati proc_fini() won't be called?)

I don't know about kern_switch.c, but the change in kern_sig.c fixes #2 on
Jeff Roberson's list of bugs in ULE (from a few days ago):
http://lists.freebsd.org/pipermail/freebsd-current/2004-December/044332.html

> I'd just contend that in the case of my system, 5_STABLE with the 4BSD
> scheduler is not stable, or at least the script I'm running is somehow
> exhausting system resources to the point that the system becomes unusable,
> and this problem isn't exhibited with the ULE scheduler.  Regardless, the
> script was causing the 5.3-RELEASE GENERIC kernel to panic, and rendered
> the system completely inaccessible with a kernel built from the latest (as
> of about 5 days ago) RELENG_5 kernel with the 4BSD scheduler.
>
> So, I'd be very grateful if ULE could be merged into RELENG_5 as it would
> dramatically improve the stability of at least my server.  Has anyone else
> with a dual amd64 system had problems like this post 5.3-RELEASE?  I know
> crashes under heavy MySQL load on dual amd64 systems were a problem
> before, but I thought that had been resolved.

I think removing the #error and putting a note on boot (and in UPDATING)
that it may still be unstable is a good idea.  However, Scott Long has
expressed reservations
(http://lists.freebsd.org/pipermail/freebsd-current/2004-December/044341.html)
and his opinion counts orders of magnitude more than mine.

Jon