Always CC Kernelnewbies. On Wed, Jul 4, 2012 at 12:52 AM, Parmenides <mobile.parmenides@xxxxxxxxx> wrote: >>> 1. For the spinlock case, it is easy to get if preemption is allowed >>> in critical section, the purpose of protection provided by spinlock >>> can not be achieved readily. >> I don't know what you mean here.Please clarify. >>> > > Sorry, this is not a problem really. :-) A critical section protected > by a spinlock is atomic. So, preemption is prohibited when kernel > enter this kind of critical section. I just want make sure it is the > case. > > >>> 2. For the interrupt context case, I think when processing interrupt, >>> kernel can be preempted in principle. But, this really increases the >>> interrupt processing time which further cause longer response time and >>> data missing in device. Except that, is there any other reasons? >> data missing in device.Can you elaborate that? >> Stack space is pretty limited in ISR context.Does that give you a clue? >>> > > data missing: For example, if a interrupt sent by Ether card can not > processed for a long time, some frames received from the cable might > be discarded owing to its limit buffer on card. > Actually, every process has its kernel stack. If a preemption occurs > during interrupt processing, the stack of another process is used. So, > I think stack space is not a problem at all. https://lkml.org/lkml/2007/8/3/2 this thinks otherwise.Please read this as stack space is one of the reasons why sleeping is not allowed in ISR context. > > >>> 3. Kernel is responsible for prohibiiting passive process switches, >>> namely preemption, in the above cases. But, It seems that it does not >>> take care of active process swtiches, namely yield. For example, some >>> code in a critical section protected by a spinlock can invoke >>> schedule() to switch process passively. Is this the case? >> I don't understand this question but we don't switch when we are holding >> spinlock as that will jeopardize the integrity of the system i.e. >> suppose you slept while holding spinlock.What would happen? > > So, kernel maintains its integrity relying on that we don't yield > while in interrupt handler or critical section protected by a > spinlock. If we do so, kernel do nothing at all. Why doesn't it refuse > schedule when it finds out that we yield in a improper context. AFAIK it prints some kind of warning message.Why don't you try this? Call schedule in ISR context(try in threaded ISR) and share with us the results. _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
