I found out Linux has no limit to how fast user-land programs can spawn children. One such misbehaving program might, for instance, fork() (that is create) too many processes too quickly and the kernel becomes so busy with itself it cannot cater to its other responsibilities. One of the tasks of a kernel is to make sure the system remains firmly under its control even in situations of misbehaving programs. Only the root user can change the class of the current task via the sched_setscheduler syscall. Thert_priority of the SCHED_RR class works exactly like the normal priority field for of the SCHED_OTHER (default) class. If at least one real-time task is running, none SCHED_OTHER task will be able to run in any CPU.Įach RT task has an rt_priority so the SCHED_RR class will be allowed to distribute the CPU power between all the SCHED_RR tasks at will. So the CPU power will be distributed between all SCHED_RR tasks. Tasks running in SCHED_RR are real time too, but they will leave the CPU if there is another real-time task in the runqueue. They will leave the CPU _only_ for waiting sync kernel events or if an explicit sleep or reschedule is been requested from userspace. Tasks running in SCHED_FIFO will _never_ be pre-empted. SCHED_OTHER tasks are the normal user tasks (default). cut and past from linux/include/linux/sched.h. cut and past from linux/include/linux/sched.h -Ģ. In Linux 2.2.x there are three classes of processes, as can be seen from the data definition for the scheduler:ġ. Scheduling ClassesWhat kind of scheduling classes are there in Linux? Much to my surprise, here again, Linux goes the unorthodox way and disregards conventional wisdom in kernel theory. This time, we dwell a bit on the subject of scheduling. Many thanks to all of them, but especially to Andrea Arcangeli who has shown a lot of patience in answering many of my questions. Without the contribution of people like Andrea Arcangeli in Italy (VM contributor and SuSE employee), Ingo Molnar (scheduler contributor) and many others, this series wouldn't be possible. In that first part, we looked at how Linux manages processes and why in many ways Linux is better at creating and maintaining processes than many commercials Unixes.This series on Linux internals is by the way the fruit of a tight collaboration with some of the most experienced kernel hackers in the Linux project. Next message: jw schultz: "Re: Bugzilla bug # 322 - double logical operator drivers/char/sx.Last month, we started a new series of Linux kernel internals.The body of a message to majordomo info at To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please pardon my stream-of-consciousness style in this post. Mean the CPU hog shares negative points with the other process? If one process is a CPU hog (or perceived as such), and it is blockingĪgainst another process, thus sharing interactivity points, does that Interactive, then, REALLY, you would want the sleeping of the second Now, if the other process is interactive, then you have a fight on yourĭoes the interactive process accumulate and share interactivity pointsįast enough to keep the other one moving well? If one process is Some other IPC) as a timeslice expiration. Simpler still would be to treat sleeping on a semaphor (or a pipe or That means you have to catch all other reasons and make sure you'veĪccounted for them, but you get the idea. Isn't in the list, you infer that it's timeslice expiration. Timeslice expiration isn't one of them, so whenever your sleep-reasons Whole list of different sleep-reasons (Schlafgruende?), it's just that ![]() ![]() Time-slice expiration in your heuristics, at least directly. Which I'm sure already happens, but the difference is that you do not What kinds of sleep a process does (counters of the various sorts), The situation is that both processes really ARE CPU hogs, but we don'tĭetect that based on using up the timeslice. On I/O or any other sleeping that WOULD indicate interactivity. The next thing to do is to somehow notice that the process never sleeps Not be able to achieve interactive status based on their sleep patterns. If certain kinds of sleep, such as sleeping on a semaphor, do not addĪny interactivity points, but the act of sleeping on a semaphor DOESĬause SHARING of interactivity points, then those two processes would One comment on two processes bouncing a semaphor. Next in thread: Felipe Alfaro Solana: "Re: Interactivity improvements".In reply to: Bernd Eckenfels: "Re: Interactivity improvements".Previous message: Jeff Garzik: "Re: Updated MSI Patches".Next message: jw schultz: "Re: Bugzilla bug # 322 - double logical operator drivers/char/sx.c".Linux-Kernel Archive: Re: Interactivity improvements Re: Interactivity improvements From: Timothy Miller ( Thu 18:05:30 EST
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |