中断返回与调度救助

wzw200

回复 9# anyhit

你现在把 ksoftirqd想成是一个进程
    do_softirq想成是一个全局变量，do_softirq函数本身实现了多CPU的互斥（互斥我们想成原子操作）

ksoftirqd函数中没有调用do_softirq的时候，可以被调度走，



   

anyhit

回复 11# wzw200
首先非常感谢你的回复。但其实还不是我的疑惑

ksoftirqd是内核线程。运行在进程上下文。同时他用一些机制，保证了执行do_softirq时软中断的一切特性（通过绑定cpu ，禁下半部，禁调度等实现）。否者ksoftirqd调用do_softirq时还跟普通进程一样，对开发者是很麻烦的，比如锁机制就不同了（中断中的锁不能随眠，进程上下文可以睡眠）


do_softirq 是一个函数，分配内存在代码段，且固定不变(详细可以了解下elf文件等)

如
        asmlinkage void __do_softirq(void)
{
        struct softirq_action *h;
        __u32 pending;
        int max_restart = MAX_SOFTIRQ_RESTART;
        int cpu;

        pending = local_softirq_pending();
        account_system_vtime(current);

        __local_bh_disable((unsigned long)__builtin_return_address(0));
        lockdep_softirq_enter();

        cpu = smp_processor_id();
restart:
        /* Reset the pending bitmask before enabling irqs */
        set_softirq_pending(0);

        local_irq_enable();
        h = softirq_vec;

因为pending  取到了 per cpu的变量（pending是局部变量，所以他本身就是在栈中分配空间）
那么若开中断后被打断了执行

这时候cpu会保存环境和堆栈 。比如 cpu寄存器环境，当前代码地址寄存器 值（假设运行在cpu1）等压栈

等中断结束了
若这些堆栈 恢复到之前执行的cpu1，那么ok没问题
但是若被恢复到了另外一个cpu2上，问题就来了。因为pending 已经取得了per cpu变量，所以其实是cpu2 执行cpu1的软中断

对于对称处理器系统
从理论上来说 中断环境是不允许上面的情况发生的
但是进程环境完全可以允许这么做。且这么做后，可以减少跨cpu的开销。比如
task1运行在cpu1---》被中断---》task1恢复到cpu1----》task1调度到cpu2
task1运行在cpu1---》被中断---》task1恢复到cpu2
第二种情况就少了一次跨cpu的开销

当然实际中考虑到cache击中等可能没那么简单


那么具体是如何实现的。我是这里产生了疑问

现在只是进一步确定了 软中断不会跨cpu，对开发来说就没什么影响了，但其实更深层的疑问并没有消除

wzw200

回复 12# anyhit


    你的问题我没有看明白了，不过我觉得你现在是钻一个地方出不来了

你从原生的 irq_enter() irq_exit（）看好理解点，
还有什么时候才可以调度这类的，跟你那个HIT有什么关系

task1运行在cpu1---》被中断---》task1恢复到cpu2
这个是不是你自己想出来的

task1这个在task_schedule的时候，就注定他只能在一个CPU上运行了，
我跟你说的那本书你看了没！！？

anyhit

回复 13# wzw200

你的问题我没有看明白了，不过我觉得你现在是钻一个地方出不来了
其实有些问题，你不知道也没关系。但总感觉如鲠在喉 不太爽


你从原生的 irq_enter() irq_exit（）看好理解点，
这个还没到我产生问题的哪层。我产生问题的那层。在irq_exit之后

还有什么时候才可以调度这类的，跟你那个HIT有什么关系
调度一般发生在
从中断返回 用户空间
从中断返回 内核空间（开抢占）
从异常（系统调用）返回用户空间
这个几乎上所有资料都是一致的


task1运行在cpu1---》被中断---》task1恢复到cpu2
这个是不是你自己想出来的
是我想出来的。但我搜集到的资料也是两种声音。而且如果排除per cpu等竞争资源的访问，从理论上有什么不合理呢？

task1这个在task_schedule的时候，就注定他只能在一个CPU上运行了，
其实这个跟我的理解是一致的
就是说 只有调度了才会发生cpu的切换。否者per cpu变量的获取就很危险了
而中断由于没法调度。所以不会发生cpu的切换。那么问题来了，软中断的SMP负载均衡是如何实现的。这个是我下一步要研究的

这个也是大多数资料的理解。
我搜集的资料包括两种方向
1.调度才会有cpu的切换 2.中断的恢复就会有cpu的切换
当然cpu的切换是非常复杂的。一般认为能不切换就不切换。否者万一cache不一致。访存的消耗就成了瓶颈。关于这个做过一些实际的测试，处理某些频繁的单一任务的时候，开SMP性能反而下降


我跟你说的那本书你看了没！！？
这个有空我了解下。现在确实很难看大部头的书了。因为很多时候，时间消耗了，发现不是自己想要的
   

anyhit

回复 13# wzw200
重新整理了下思路 和搜了下资料。更明白了些。这里分享出来。

http://
blog.csdn.net/shaohaigod1981/article/details/4768449
从中断返回，也就是irq_exit之后
ENTRY(ret_from_intr)
        GET_CURRENT(%ebx)
ret_from_exception:
         movl EFLAGS(%esp),%eax          # mix EFLAGS and CS
         movb CS(%esp),%al
         testl $(VM_MASK | 3),%eax       # return to VM86 mode or non-supervisor?
         jne ret_from_sys_call
         jmp restore_all

果中断发生在内核空间，则控制权直接转移到标号restore_all。如果中断发生于用户空间（或VM86模式），则转移到ret_from_sys_call：


ENTRY(ret_from_sys_call)
         cli                             # need_resched and signals atomic test
         cmpl $0,need_resched(%ebx)
         jne reschedule
         cmpl $0,sigpending(%ebx)
         jne signal_return
restore_all:
         RESTORE_ALL
need_resched(%ebx)表示当前进程task_struct结构中偏移量need_resched处的内容，如果调度标志为非0，说明需要进行调度，则去调用schedule（）

__schedule
中                idle_balance(cpu, rq); 负责smp下的cpu切换（负载均衡）
context_switch 负责切换到新的进程。switch_to负责堆栈等恢复

再结合83兄的两文章
应该就能搞懂了。后面再看下堆栈恢复相关的
   

wzw200

回复 14# anyhit


    LINUX内核为了设计操作系统方便，自己做了好多限制，
我也是看的别人的帖子，