Re: Comments on the KSE option


On 28 Oct 2006, at 11:04, Robert Watson wrote:


On Sat, 28 Oct 2006, David Xu wrote:

3) Third, it adds overhead to scheduler (I have already post a number) and might make locking more diffcult for per-cpu queue like scheduler, since now you always have to contend the ksegrp runqueue lock between many CPUs, also because you have build the fairness in the scheduler and every scheduler must obey the ksegrp algorithm, it may make more diffcult to implement another alogrithm and replace it, see 4).

This is my single biggest concern: our scheduling, thread/process, and context management paths in the kernel are currently extremely complex. This has a number of impacts: it makes it extremely hard to read and understand, it adds significant overhead, and it makes it quite hard to modify and optimize for increasing numbers of processors. We need to be planning on a world of 128 hardware threads/machine on commodity server hardware in the immediate future, which means that the current "giant sched_lock" cannot continue much longer. Kip's prototypes of breaking out sched_lock as part of the sun4v work have been able to benefit significantly from the reduced complexity of a KSE-free kernel, and it's fairly clear that the task of improving schedule scalability is dramatically simpler when the kernel model for threading is more simple. Regardless of where the specific NO_KSE option in the kernel goes, reducing kernel scheduler/etc complexity should be a first order of business, because effective SMP work really depends on that happening.


I would add another concern - While I understand why fairness are useful in resource allocation - I do not think it makes sense unless the principle are use against all limited resources and hence in order for it to make sense it would mean a major rework of all allocation structures in the kernel. After all what is the use of getting CPU time of all file descriptors are used by another process etc. etc. In short the "fairness" proposed only a partial guarantee not a truly useful end-user situation.
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: call for more SD versus CFS comparisons (was: Re: [ck] Mainline plans)
    ... problems on my Amarok machine. ... usually test Amarok playback while kernel package make, ... Putting load onto the VM layer / block layer. ... also the behavior on a server for example - how does the scheduler behave ...
    (Linux-Kernel)
  • Re: page fault in sched_pin()
    ... > sched_pinearly in the boot process. ... I wasn't booting off the kernel I thught I was booting off. ... remove it from the scheduler inteface and make it part of the standard ... page fault while in kernel mode ...
    (freebsd-current)
  • Re: BIND9 performance issues with SMP
    ... instead of having its own dedicated scheduler activation. ... that threads that block in the kernel don't block the whole process. ... but lock contentions seem particularly heavy ... The first-level optimization is to create ...
    (freebsd-current)
  • Re: thread and process
    ... in the kernel, 1:n-threading, using a userspace scheduler for threads ... Since Linux is not UNIX, ... a set of such tasks sharing certain ressource structures 'looks like' ...
    (comp.unix.programmer)
  • Re: [OT] Interview with Con Kolivas on Linux failures
    ... Con Kolivas, the kernel hacker who authored a better scheduler, recently decided to quit. ... Loss for Linux ... The former option means you have a CPU scheduler which is difficult to model, and the behaviour is right 95% of the time and ebbs and flows in its metering out of CPU and latency. ...
    (Debian-User)