polling / interrupt
|
From: Tim McCaffrey on 1 Jun 2010 11:40 In article <slrnhvu86e.1ho.rivie(a)stench.no.domain>, rivie(a)ridgenet.net says... > >On 2010-05-27, FredK <fred.nospam(a)dec.com> wrote: >> The DEC PDP-11 was a single processor minicomputer from the 70's (there was >> a dual CPU 11/74 IIRC). On these systems it was not feasible from a >> cost/complexity viewpoint to implement "IO channel" processors. Just as it >> wasn't reasonable for those systems/CPUs that ultimately resulted in the >> x86. > >http://en.wikipedia.org/wiki/Intel_8089 The 8089 was a crippled in such a way that it couldn't be used to control more than one device (it was really two controllers in the package, so two devices), and you couldn't put subroutines in ROM, because they didn't use a stack for calls (they used a CDC 6600 like return jump). It was also expensive. - Tim
From: Noob on 3 Jun 2010 11:17 yoxoman wrote: > It seems that polling is the "dirty" way of using a device, whereas > interrupt is the prefered one, but that one implies some context > switching delays. > > Are there still devices today on which polling is used (I think of > keyboard and mouse, but I'm not sure) ? Are the both techniques used on > some devices ? Does it depend on the OS ? There are situations where polling makes sense. Consider a high-throughput NIC constantly interrupting the CPU. Keywords: interrupt mitigation, interrupt coalescing cf. also http://en.wikipedia.org/wiki/New_API
From: Philip Koopman on 3 Jun 2010 13:56 Andy 'Krazy' Glew <ag-news(a)patten-glew.net> wrote: > think it was ECN - something that might be paraphrased as: ><< > >Automotive engineers are tired of having too many microprocessors. .... >Worse, all of the little processors allocated to specific tasks have to be sized so that they can handle the worst case >workload. > >It's much more efficient to have fewer, larger processors - since the worst case workload for the separate tasks seldom >happens all at the same time. So that instead of having N*WorstCaseNeed, you have 1 processor of size N*AverageNeed + >M-sum of worst cases, where M is the largest number of worst cases that will ever happen together. > > >> > >Truly, this isn't me, except paraphrasing. > >Now, magazines like ECN are often just shilling for whoever wrote the article. But obviously some embedded processor >vendor for automotive felt that an argument like the above was compelling. Yes, the auto companies want to do this. They are coming to terms that they have to be software system integrators and having fewer big CPUs helps with that as well with reducing mechanical component count (components = cost). But it is not going to be easy: - You still have to handle the worst case of possible concurrently active worst caes, even if it is unlikely (often down to 10^^-9 per hour unlikely if it is safety critical) - You have to make sure tasks developed by different vendors can't interfere, and real time performance matters a lot. Sizing to the average doesn't usually cut it if you care about real time and safety. At least with current methods. (I realize Andy you were just quoting the article, so this criticism is directed at the author you are paraphrasing and not at you.) Cheers, -- Phil Koopman Phil Koopman -- koopman(a)cmu.edu -- http://www.ece.cmu.edu/~koopman Author of: Better Embedded System Software, Drumnadrochit Press 2010
From: Rick Jones on 3 Jun 2010 14:01 Noob <root(a)127.0.0.1> wrote: > There are situations where polling makes sense. > Consider a high-throughput NIC constantly interrupting the CPU. > Keywords: interrupt mitigation, interrupt coalescing I would not equate interrupt coalescing with polling, merely with being "smarter" about when to generate an interrupt. Alas, some NICs and their drivers don't do coalescing in what I would consider a "smart" way and so affect unloaded latency at the same time. rick jones -- a wide gulf separates "what if" from "if only" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
From: EricP on 3 Jun 2010 19:44
Rick Jones wrote: > Noob <root(a)127.0.0.1> wrote: >> There are situations where polling makes sense. > >> Consider a high-throughput NIC constantly interrupting the CPU. > >> Keywords: interrupt mitigation, interrupt coalescing > > I would not equate interrupt coalescing with polling, merely with > being "smarter" about when to generate an interrupt. Alas, some NICs > and their drivers don't do coalescing in what I would consider a > "smart" way and so affect unloaded latency at the same time. > > rick jones For example, this investigation by DEC/ATT in 1995 used the first interrupt to trigger the OS. Then under high load it would switch to polling. They also changed the order that TCP/IP packets were processed because using the order delivered is not necessarily the most optimal. For example, if packets had to be tossed due to buffer shortages, shut off interupts, free the packets that have the least investment in them so the host can receive more packets and make progress on others. Eliminating Receive Livelock in an Interrupt-driven Kernel http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-95-8.html Eric |