各位大侠进来看看 同样程序suse和centos 占有cpu不一样

zylthinking

shan_ghost 发表于 2013-01-17 15:19
记得好像是linus或者那几个人说的，也可能是偶自动综合了他们的言论：大意就是2.4的内核能提供更精确的时钟 ...

在没有看到原文前， 我也怀疑你这些话； 我很怀疑你又拿什么所谓资料做噱头然后蒙我；
就原理来讲， timer list 执行时位于中断下半部， 那么必然是随机发生于各个进程上下文内， 不会单单看着调用了 sleep 的进程好欺负； timer list  并不会因为调用了 sleep 而存在， 没有了 sleep 就不存在了； CPU 的消耗不会有区别；
最重要的是， 无论如何， 得不出你所谓不应该调用 sleep 来等待什么信号的结论来， 或者说 sleep 不是为让出 cpu 来设计的， 靠， 那他是为什么来设计的？

shan_ghost

靠，抓源码，看来是我记错了：

首先。2.4内核，小于2ms、且current->policy != SCHED_OTHER会忙等，而且不会出现任务切换：
（current->policy != SCHED_OTHER的意思是检查当前进程是否实时进程，只有是实时进程才会忙等，否则仍然发生任务切换。）

http://students.mimuw.edu.pl/SO/Linux/Kod/kernel/sched.c.html

asmlinkage int sys_nanosleep(struct timespec *rqtp, struct timespec *rmtp)
{
        int error;
        struct timespec t;
        unsigned long expire;

        error = verify_area(VERIFY_READ, rqtp, sizeof(struct timespec));
        if (error)
                return error;
        memcpy_fromfs(&t, rqtp, sizeof(struct timespec));
        if (rmtp) {
                error = verify_area(VERIFY_WRITE, rmtp,
                                    sizeof(struct timespec));
                if (error)
                        return error;
        }

        if (t.tv_nsec >= 1000000000L || t.tv_nsec < 0 || t.tv_sec < 0)
                return -EINVAL;

        if (t.tv_sec == 0 && t.tv_nsec <= 2000000L &&
            current->policy != SCHED_OTHER) {
                /*
                 * Short delay requests up to 2 ms will be handled with
                 * high precision by a busy wait for all real-time processes.
                 */
                udelay((t.tv_nsec + 999) / 1000);
                return 0;
        }

        expire = timespectojiffies(&t) + (t.tv_sec || t.tv_nsec) + jiffies;
        current->timeout = expire;
        current->state = TASK_INTERRUPTIBLE;
        schedule();

        if (expire > jiffies) {
                if (rmtp) {
                        jiffiestotimespec(expire - jiffies -
                                          (expire > jiffies + 1), &t);
                        memcpy_tofs(rmtp, &t, sizeof(struct timespec));
                }
                return -EINTR;
        }

        return 0;
}

libc的sleep/usleep实现，其实就是直接调用了sys_nanosleep，所以分析sys_nanosleep就行了：
http://cristi.indefero.net/p/uCl ... libc/unistd/sleep.c
http://cristi.indefero.net/p/uCl ... ibc/unistd/usleep.c


总之，看来我之前看到那篇文章是错的。2.4的改变，除了更好的支持了实时程序外，其实并不会造成任何可见影响。

shan_ghost

zylthinking 发表于 2013-01-17 16:13
在没有看到原文前， 我也怀疑你这些话； 我很怀疑你又拿什么所谓资料做噱头然后蒙我；
就原理来讲， t ...

呵呵，是我错了。当时看到那篇文章时没认真鉴别，学到错误的东西了……

mordorwww

真sleep 1us的话CPU占用很高吧，你想1us做一次进程调度和切换，1ms做一千次
而如果忙等的话，你这进程就一死循环， CPU占用100%了吧
见过脚本里睡眠太频繁CPU占用就很高，百分之几十(600Mhz arm)

windoze

回复 24# mordorwww

楼上考的一手好古。
正纳闷这个HighRes Timer的锅怎么又冒出来了，仔细一看原来是3年前的帖子……

mordorwww

windoze 发表于 2016-06-27 02:10
回复 24# mordorwww

楼上考的一手好古。

回帖里提到的等待信号 是什么，百度 谷歌都没搜到这个概念
而且我验证在 CentOS release 6.5 (Final) 版本 里确实如楼主所说。
每1us醒来一次，这个不会让CPU占用很高么

感觉这个应该移到内核版

windoze

回复 26# mordorwww

这是HiRes Timer惹的祸，之前计时用的是jiffy，这个东西没成本但是不准，后来改成HiRes Timer了，这个东西很准但是有点贵。

mordorwww

windoze 发表于 2016-06-27 10:19
回复 26# mordorwww

这是HiRes Timer惹的祸，之前计时用的是jiffy，这个东西没成本但是不准，后来改成H ...

1s 钟做 1百万次 sleep操作，i3  CPU占用才5%（1Ghz arm占用 18%），那说明现在CPU很强大嘛，HiRes Timer也不算太贵嘛



1Ghz arm
  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND                                                                                                                          
3824 root      20   0    1192    236    184 S 19.3  0.0   0:35.32 r


3.4Ghz i3
PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                                
28383 root      20   0  3920  340  276 S  4.3  0.0   2:56.14 r                                                                                                                                      
8056 root      20   0  3920  344  276 S  4.0  0.0   0:00.32 r

fender0107401

学习学习。

cokeboL

挖的一手好坟