Date: Fri, 27 Apr 2001 23:06:01 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: arch@freebsd.org, terry@lambert.org Subject: Re: KSE threading support (first parts) Message-ID: <200104272306.QAA13810@usr02.primenet.com>
next in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote: ] It doesn't seem like that's what Daniel is saying, which is that ] the default will be like this, but that applications or the startup ] code will have the choice. ] ] However that's true then we might as well scrap the project, it ] just brings the complexity out of userland and into the kernel, ] sure we can schedule IO better, but then we might as well cop out ] and use aio and some special signal system for handling faults back ] into the uts. It's just a lot simpler to go with rfork threads or ] a simpler model than all this complexity just to satisfy Terry's ] view of who should get what quantum. Honestly if you ask anyone ] they expect to be able to cheat with threads the same way they ] cheat by using multiple processes to gain additional CPU. I personally do not give a flying " " if processes cheat in order to compete unfairly for quantum; that's an administrative issue, and I think FreeBSD already has far too many arbitrary limits to "protect" the user from doing useful work^W^W^Whurting themselves. My main emphasis has always been: o Minimize context switch overhead o Reduce the overal scheduler complexity; in particular, IMO, it is nearly impossible to get thread group affinity to work correctly by hacking up a scheduler, without resulting in starvation for other processes, so The Scheduler Is Not The Place To Do Affinity. o I would like to see SMP scalability The approach which Julian touts tends to fail to achieve SMP scaling, unless you explicitly ask for it. In Julian's model, there is a KSEG per CPU on which you want to be able to run, and all KSEs live in the context of a KSEG. In the Julian and Archie model, KSEs do _not_ move between KSEGs, without an Act Of God. I think this model is wrong. I would completely discard the concept of a KSEG, entirely. In place of that "easy CPU affinity" model, which is what it is intended to gurantee, I would create per-CPU run queues. I would control affinity and load balancing through the decision to migrate or to not migrate a particular KSE between CPUs. In other words, the complexity of the model which Jason Evans arrived at from the Big Threads Design Meeting in Foster City that about 120 of us attended, is optimal for achieving my design goals, without going to ascyn call gates. IMO, going to async call gates could result in as much as an additional 25% improvement in performance. Unfortunately, it would also mean a lot of extra overhead to ensure binary backward compatability, since it would put all of the standard POSIX semantics into the libraries, and the default behaviour would be completely asynchronous. Binary compatability would mean using a different INT than INT 0x80 for system calls, and putting backward compatability cruft into a module to support any binary which some moron decided to link static because they thought that linking it static makes it somehow safer from single file damage failure than using libc.so and ld.so. My ideal implementation would use async call gates. In effect, this would be the same as implementing VMS ASTs in all of FreeBSD. That all said, the current project, as it was envisioned by Jason Evans, does not have the limitations which you and Nate fear, unless you cop out on the implementation, and do what Julian and Archie wanted with KSEG non-migration of KSEs (and the concommitant single scheduler run queue for all CPUs), or if you take Matt's approach, and serialize execution everywhere, not just within a particular KSEG (Matt's approach prevents the need for a single process to be able to exist on a run queue as more than one entry instance, which makes some things easier). I would call both the Matt approach, and the Julian/Archie approach "overly conservative"; they are both in excess of 12 years behind the state of the Art. But I would also level the same criticism at using the 6 year old technology of scheduler activations to avoid going to true async call gates. In any case, you and Nate are getting upset at shortcuts that people want to take in implementation, not at the design itself. Cut it out. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104272306.QAA13810>