From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6394e5e171f847d1 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-09-05 10:24:05 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!paloalto-snf1.gtei.net!crtntx1-snh1.gtei.net!lsanca1-snf1!news.gtei.net!newsfeed2.earthlink.net!newsfeed.earthlink.net!news.mindspring.net!not-for-mail From: "Brian Catlin" Newsgroups: comp.lang.ada Subject: Re: Ada OS Kernel features Date: Wed, 5 Sep 2001 10:23:34 -0700 Organization: Sannas Consulting Message-ID: <9n5n33$ke5$1@nntp9.atl.mindspring.net> References: <9n4euv$t9m$1@slb6.atl.mindspring.net> NNTP-Posting-Host: d1.56.dc.81 X-Server-Date: 5 Sep 2001 17:23:47 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Xref: archiver1.google.com comp.lang.ada:12760 Date: 2001-09-05T17:23:47+00:00 List-Id: "Ted Dennison" wrote in message news:Khql7.4732$4z.14760@www.newsranger.com... > In article <9n4euv$t9m$1@slb6.atl.mindspring.net>, Brian Catlin says... > >Scheduler: > > I think that the kernel should support three types of tasks: isochronous, > >real-time, and general purpose. An isochronous task is a periodic time-driven > >task with performance requirements for bounded latency and jitter, and > >guaranteed throughput. A real-time task has performance requirements for low > >latency and high throughput. Both isochronous and real-time tasks have bounded > >execution times, so that the system can bound latency and jitter for other such > >tasks. In contrast, a general purpose task is characterized by lengthy or > > Interesting. I've never seen them broken out that way. Is that a typical way of > thinking about real-time tasks these days? In fact, I have trouble finding good > references for dealing with RT tasks that have jitter requirements. As near as I > can tell, any such task has to be scheduled in such a way that it is the first > task to get run after its designated clock tick. Obviously this means you can't > create a whole lot of these... An isochronously scheduled task means that the task will get a fixed amount of CPU time over time (think of it as getting a fixed percentage of the CPU over time). Supporting isochronous tasks is a requirement if you want to be able to handle streaming multimedia, such as audio or video. A simple way to implement this, would have the scheduler use a weighted round robin scheme for scheduling real-time and general purpose tasks. Isochronous tasks would be driven off timer interrupts. The kernel would assign a scheduling flag and a weight to each real-time task. To schedule realtime tasks, the would scheduler poll a set of flags, each of which indicates a pending task. For each flag that is set, the scheduler would invoke the corresponding real-time task, with the assigned weight as a parameter. A scheduling flag may be set by an interrupt service routine as well as any realtime or general purpose task in the system. As a further refinement, the kernel could introduce the notion of preemption windows. Isochronous and real-time tasks can only be preempted during their preemption windows. An isochronous task could be preempted by higher priority isochronous tasks; real-time tasks could be preempted by isochronous tasks. Preemption windows would be placed at the completion of a unit of work, where little state needs to be saved in context-switching to the new task. A real-time task would be expected to process at most the number of work units equal to the weight passed to it as a parameter. Upon completion, the task saves its state, if necessary, and voluntarily returns to the scheduler. After having completed one round of polling for real-time tasks, the scheduler would switch to the list of general purpose tasks. This task runs until it blocks or the quantum timer expires. If the timer expires, the scheduler saves the tasks's context and goes back to servicing real-time tasks. > >be the most natural. The layering of device drivers (as implemented) in NT > >would also seem to be a very valuable feature. > > I've started to look at NT drivers recently. I do think thier layered approach > is a cool idea, but I have one major problem with it. There doesn't appear to be > any good reason to require any but the lowest-level driver to run in kernel mode > (ring 3, supervisor, whatever you call it...) Such programs are much tougher to > debug, and bugs in them are much more catastrophic. It appears that they are > just having them run in kernel mode because that's what device drivers are > supposed to do. Yes, it makes them more difficult to debug, but placing the drivers in the kernel has several benefits: 1. Processing an I/O request requires access to privileged system routines and data structures. Allowing access to these resources from user-mode is a *BAD* idea (this is one of the major reasons why Win98 was so unstable; applications could step all over the kernel) 2. Putting drivers in user-mode means increasing the number of transitions between user-mode and kernel-mode, which is *VERY* time-consuming 3. A driver will need access to the requesting process' address space, but if the "driver" is running as part of another process, the requesting process' address space is inaccessible. -Brian