Date: Sat, 21 Apr 2018 19:21:58 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Cc: George Mitchell <george+freebsd@m5p.com>, Peter <pmc@citylink.dinoex.sub.org> Subject: SCHED_ULE makes 256Mbyte i386 unusable Message-ID: <YQBPR0101MB1042F252A539E8D55EB44585DD8B0@YQBPR0101MB1042.CANPRD01.PROD.OUTLOOK.COM>
next in thread | raw e-mail | index | archive | help
I decided to start a new thread on current related to SCHED_ULE, since I se= e more than just performance degradation and on a recent current kernel. (I cc'd a couple of the people discussing performance problems in freebsd-s= table recently under a subject line of "Re: kern.sched.quantum: Creepy, sadistic= scheduler". When testing a pNFS server on a single core i386 with 256Mbytes using a Dec= . 2017 current/head kernel, I would see about a 30% performance degradation (elaps= ed run time for a kernel build over NFSv4.1) when the server kernel was built = with options SCHED_ULE instead of options SCHED_4BSD Now, with a kernel from a couple of days ago, the options SCHED_ULE kernel becomes unusable shortly after starting testing. I have seen two variants of this: - Became essentially hung. All I could do was ping the machine from the net= work. - Reported "vm_thread_new: kstack allocation failed and then any attempt to do anything gets "No more processes". with the only difference being a kernel built with options SCHED_4BSD everything works and performs the same as the Dec 2017 kernel. I can try rolling back through the revisions, but it would be nice if someo= ne could suggest where to start, because it takes a couple of hours to build a kernel on this system. So, something has made things worse for a head/current kernel this winter, = rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQBPR0101MB1042F252A539E8D55EB44585DD8B0>