前言 今天我们来评测linux内核的高精度定时器。顺便利用通过Tektronix示波器 和 DS100 Mini 数字示波器进行交叉测试。 因项目需要用到精准的时间周期，所以要评估它的可行性，并验证正点原子的示波器能不能支撑嵌入式开发流程。 Linux高精度定时器说明 其实传统的低分辨率定时器随着技术的演进，已经无法满足开发需求。而且硬件的不断发展，硬件定时器的精度也越来越高，这也给高精度定时器创建了有利条件。 低分辨率的定时大部分时间复杂度可以实现O(1)，当有进位发生时，不可预测的O(N)定时器级联迁移
如果你想周期性的做一些事情，那么必然，会与时间产生联系。比如，每天早晨7点吃早餐，每天晚上10点进入梦乡。当然，如果你有伴侣的话，晚上这个时间可能不会这么固定。
在linux kernel里，有一个debug选项LOCKUP_DETECTOR。
实时系统要求对事件的响应时间不能超过规定的期限，响应时间是指从某个事件发生到负责处理这个事件的进程处理完成的时间间隔，最大响应时间应该是确定的、可以预测的。
惠伟：linux time和kvm time虚拟化综述zhuanlan.zhihu.com
在这篇中遗留了几个问题，先尝试回答一下，不一定准确，代码太多，看不过来，全靠猜测，代码的历史很长，都是智慧的结晶，一时半会消化不了很正常。
之前在我热爱的公众号Linuxer看到The precise meaning of I/O wait time in Linux这篇文章，感觉写的不错，就是没有落实到源码上感觉稍微有点晦涩，于是自己读了一下代码。 当task发生iowait的时候，内核对他们的处理方法是将task切换出去，让可运行的task先运行，而在切换出去前，会将其in_iowait设置为1，再次被唤醒的时候in_iowait被设置为原值。相关函数io_schedule，io_schedule_timeout，mutex_lock_io
| 导语本文主要是讲Linux的调度系统, 由于全部内容太多，分三部分来讲，本篇是中篇（主要讲抢占和时钟），上篇请看（CPU和中断）：Linux调度系统全景指南(上篇)，调度可以说是操作系统的灵魂，为了让CPU资源利用最大化，Linux设计了一套非常精细的调度系统，对大多数场景都进行了很多优化，系统扩展性强，我们可以根据业务模型和业务场景的特点，有针对性的去进行性能优化，在保证客户网络带宽前提下，隔离客户互相之间的干扰影响，提高CPU利用率，降低单位运算成本，提高市场竞争力。欢迎大家相互交流学习！
在上面工作方式下，Linux 2.6.16 之前，内核软件定时器采用timer wheel多级时间轮的实现机制，维护操作系统的所有定时事件。timer wheel的触发是基于系统tick周期性中断。
可以发现sleep主要调用clock_nanosleep系统调用来进行睡眠（也就是说用户态任务睡眠需要调用系统调用陷入内核）。
导读 | 第27届国际计量大会宣布最迟不晚于2035年取消引入闰秒，这一消息引起轰动。上一次闰秒产生，对Reddit、Mozilla、FourSquare等都产生了一定的问题，其中Reddit宕机时间超过1个半小时！本栏目特邀腾讯后台开发工程师陶松桥，带你是深入了解闰秒的来源及其影响，并介绍各类系统常见的闰秒处理方法，其中会分享TencentOS Server 操作系统的解决方案。 闰秒从何而来 世界上有几种计量时间的方式： 世界时（UT1）：是一种天文计量的方式，天文学家通过观测地球的自转，并将自转一周
无论是任务处于用户态还是内核态，经常会因为等待某些事件而睡眠（可能是等待IO读写完成，也可能等待其他内核路径释放一把锁等）。本文来探讨一下，任务处于睡眠中有哪些状态？睡眠对于任务来说究竟意味着什么？内核是如何管理睡眠的任务的？我们会结合内核源代码来分析任务的睡眠，力求全方位角度来剖析。
在面试中关于多线程同步，你必须要思考的问题 一文中，我们知道glibc的pthread_cond_timedwait底层是用linux futex机制实现的。
随着内核不断更新演进，内核对定时器的分辨率要求越来越高。硬件的高速发展也逐渐能够满足内核的这一要求，因此内核针对硬件提供的便利，开始设计了更高分辨率的定时器（hrtimer），可达到ns级别。本文主要讲解如何使用高精度定时器。
在android 手机上，如果call usleep(2*1000),结果sleep时间不定，甚至结果sleep了50+ms，是不是有点过分，测试代码如下：各位可以在手机上测试下，特别是把程序放在后台运行的情况下。
《手摸手系列》把go sync包中的并发组件已经写完了，本文作为完结篇，最后再来探讨下go运行时锁的实现。记得在《手摸手Go 并发编程的基建Semaphore》那篇中我们聊过sync.Mutex最终是依赖sema.go中实现的sleep和wakeup原语来实现的。如果细心的小伙伴会发现:
严格来说，Linux 不是实时操作系统，但 Linux 却支持实时调度算法。与通用调度算法（如完全公平调度算法）相比，实时调度算法更注重任务（进程）的实时性。为什么 Linux 支持实时调度算法，却不是实时操作系统呢？有兴趣的同学可以去网上查阅相关的文献或者资料。
继上一篇：https://cloud.tencent.com/developer/article/1054078 一、驱动流程解析： 1、模块加载： 1 static struct of_device_id stk_match_table[] = { 2 { .compatible = "stk,stk3x1x", }, 3 { }, 4 }; 5 6 static struct i2c_driver stk_ps_driver = 7 { 8 .driver =
最近在开发一个项目，需要用到高精度的延时机制，设计需求是 1000us 周期下，误差不能超过 1%（10us）。
上一篇文章我们简单了解了一些关于时间的概念，以及Linux内核中的关于时间的基本理解。而本篇则会简单说明时钟硬件，以及Linux时间子系统相关的一些数据结构。
低分辨率定时器可以分为周期性和动态性，这里只讨论周期性。在jiffies小节中知道，linux系统会在每个时钟中断会增加jiffies的值，同时还会去处理到期的定时器。而系统时钟中断的速度取决于HZ的值，如果HZ配置为1000，则每秒会产生1000次时钟中断。如果按照样的话，是不是HZ的值越大越好，其实不然。如果HZ的值越大，则会造成系统的负载也会越大。所以HZ的值一般在每个平台是不一样的。假设HZ=250,那么系统会在每4ms会产生一个时钟中断，然后会去处理超时的定时器。但是4ms对有些设备是可以满足的，对一些要求延迟到us的设备是不满足的，所以linux设计者就推出了高精度定时器Hrtimer，所以把之前依赖HZ的值的定时器称为低分辨率定时器。
在《宋宝华：火焰图：全局视野的Linux性能剖析》一文中，我们主要看了on-cpu火焰图，理解了系统的CPU的走向的分析。但是，很多时候，单纯地看on-cpu的情况（什么代码在耗费CPU），并不能解决性能问题，因为有时候性能差的原因瓶颈不一定在CPU上面，而是在off-cpu的时间，比如：
前几天我在看一篇公众号文章《DBA接招：一次因PAUSE指令变化引发的MySQL性能危机》 文章写得很棒，分析地也很彻底，但是更吸引我的是文中的几张图，例如
假设现在一家公司就有一名客服人员，这个客服人员就有一台座机，这种情况下用户碰到问题只能打电话给这个客服人员，如果有多个用户同时打入只能凭运气，先打通电话的人得到回答，其他人只能依次等待。显然这种处理机制是非常低效的，小公司可能还可以，大一点的公司就不行了。于是现在共有4-5位客服人员，建立总分机架构，1位负责总机（也可以交给语音提示来操作），负责把问题分给4个分机，让4个分机人员来处理具体的问题，这样一来效率就明显提高了。如果客户来电，总机负责人接电话分给分机人员（或通过语音提示用户拨打分机号）叫做硬中断，而分机负责人处理具体问题叫做软中断。Linux的CPU正是采用硬中断与软中断结合的方式来处理问题的。比如现在网卡告诉CPU，有一批数据要从网络中过来，希望系统做好接收准备，CPU手头的工作被打断（中断），将网络上的数据存储在寄存器中，然后呼起一个进程来处理后续操作，就回头处理刚才中断之前的工作了。被呼起的进程可以在后台“慢慢地”地把寄存器中的数据按照规定格式写入数据库中。这里CPU处理的过程就为硬中断过程，而进程把数据写入数据库中过程为软中断过程。具体如图3-19所示。
操作系统内核对应用开发工程师来说就像一个黑盒，似乎很难窥探到其内部的运行机制。其实Linux内核很早就内置了一个强大的tracing工具：Ftrace，它几乎可以跟踪内核的所有函数，不仅可以用于调试和分析，还可以用于观察学习Linux内核的内部运行。虽然Ftrace在2008年就加入了内核，但很多应用开发工程师仍然不知道它的存在。本文就给你介绍一下Ftrace的基本使用。
软中断的出现和linux系统对中断的划分是分不开的。linux系统将整个中断处理过程分为了两部分，分别为上半部(Top Half)和下半部(Bottom Half)，之所以要这样分是因为关闭中断的时间不能过长，也就是在关闭中断期间尽可能少干事，否则影响整个系统的性能。所以linux系统将中断处理分为两部分，在上半部全程关闭中断，下半部打开中断。而在上半部主要干一些和硬件有关的操作，速度快，在下部分做一些耗时的操作。这样一来既能保证系统效率又能处理各种中断。
Linux kernel支持两种实时(real-time)调度策略(scheduling policy)：SCHED_FIFO和SCHED_RR，无论是哪一种，实时进程的优先级范围[0~99]都高于普通进程[100~139]，始终优先于普通进程得到运行。如果实时进程是CPU消耗型的，会不会导致其它进程得不到运行机会，造成系统lockup呢？
实时分为硬实时和软实时，硬实时要求绝对保证响应时间不超过期限，如果超过期限，会造成灾难性的后果，例如汽车在发生碰撞事故时必须快速展开安全气囊；软实时只需尽力使响应时间不超过期限，如果偶尔超过期限，不会造成灾难性的后果.
之前使用ftrace的时候需要一系列的配置，使用起来有点繁琐，这里推荐一个ftrace的一个前端工具，它就是trace-cmd
在linux内核系统中，各个模块、子系统之间是相互独立的。Linux内核可以通过通知链机制来获取由其它模块或子系统产生的它感兴趣的某些事件。
硬件架构 从硬件架构图中可以看出以下特点： 每个 CPU 核都包含各自的 local timer，相互独立。 每个 local timer 都支持中断的产生，中断类型为 PPI，即 CPU 的私有中断，GIC 负责分发到指定的 CPU，这些中断都可以用来产生系统事件。local timer的中断为以下四种： Secure Physical Timer event (ID 29，也就是上面device node中的13，29 = 16 + 13) Non-secure Physical Timer even
比如说你订了一份外卖，但是不确定外卖什么时候送到，也没有别的方法了解外卖的进度， 但是，配送员送外卖是不等人的，到了你这儿没人取的话，就直接走人了；所以你只能苦苦等着，时不时去门口看看外卖送到没，而不能干其他事情；不过呢，如果在订外卖的时候，你就跟配送员约定好，让他送到后给你打个电话，那你就不用苦苦等待了，就可以去忙别的事情，直到电话一响，接电话、取外卖就可以了、
Linux内核的软中断("softirq")机制有些奇怪，在早期的Linux和处理机制下比较晦涩，且仅有极少的内核开发人员会直接接触软中断。然而它是内核的大多数重要处理的核心。在某些场景下，软中断会以一种不合时宜的方式出现。特别是内核的实时抢占补丁集经常会与软中断产生冲突，该补丁集的最新版本提供了一种解决产生软中断问题的方法，值得一看。
负载是查看 Linux 服务器运行状态时很常用的一个性能指标。在观察线上服务器运行状况的时候，我们也是经常把负载找出来看一看。在线上请求压力过大的时候，经常是也伴随着负载的飙高。
本文为joshua317原创文章,转载请注明：转载自joshua317博客 https://www.joshua317.com/article/196
中断其实就是由硬件或软件所发送的一种称为IRQ（中断请求）的信号。中断允许让设备，如键盘，串口卡，并口等设备表明它们需要CPU。
踏上 Linux 内核世界的探险将成为您职业生涯的一段迷人旅程。作为操作系统之心的 Linux 内核涵盖众多领域，如操作系统原理、硬件抽象以及驱动开发等。在这篇文章中，我们将一探 Linux 内核的奥秘，并为具备编程基础的技术人员提供一处学习起点。
1. mpstat命令 1.1 命令格式 mpstat [ -A ] [ -u ] [ -V ] [ -I { SUM | CPU | SCPU | ALL } ] [ -P { cpu [,...] | ON | ALL } ] [ interval [ count ] ] OPTIONS: -A: 等同于-u -I ALL -P ALL -I:可以指定SUM CPU SCPU ALL四个参数,SUM表示每个处理器的中断总数，CPU表示每个核的每秒中断数量， SCPU表示每个核每秒的软中断数
一，softlockup: watchdog软狗/软锁----用于检测系统调度是否正常。 能响应中断，但调度异常。
epoll的事件触发机制有两种，分别为 level-triggered 和 edge-triggered。
本篇文章算是一篇读书笔记，基本上是把CPU相关的知识作了一个归纳整理，方便后续查看和排查问题。
前些天发现XEN虚拟机上的Nginx服务器存在一个问题：软中断过高，而且大部分都集中在同一个CPU，一旦系统繁忙，此CPU就会成为木桶的短板。
timer就像是系统的脉搏，重要性不言而喻。ARMv8架构处理器提供了一个Generic Timer，与GIC类似，Generic Timer在硬件上也支持了虚拟化，减少了软件模拟带来的overhead。
周期性调度器的工作由scheduler_tick函数完成(定义在kernel/sched/core.c, line 2910), 在scheduler_tick中周期性调度器通过调用curr进程所属调度器类sched_class的task_tick函数完成周期性调度的工作
Workqueue 工作队列是利用内核线程来异步执行工作任务的通用机制，利用进程上下文来执行中断处理中耗时的任务，因此它允许睡眠。而 Softirq 和 Tasklet 在处理任务时不能睡眠。Softirq 是内核中常见的一种下半部机制，适合系统对性能和实时响应要求很高的场合，比如网络子系统，块设备，高精度定时器，RCU 等。
RTC（real-time clock）简称实时时钟，主要作用是用来记时，产生闹钟等。RTC因为有备份电池，所以即使计算机关机掉电，也不会影响RTC记时。而RTC和系统时间(主要靠软件模拟)的区别在于，RTC会在掉电后数据不丢失，在下次启动依旧可以重新设置当前时间给计算机。而系统时间主要靠软件模拟产生，在掉电之后会丢失，需要在下次计算机重新启动之后重新模拟产生。RTC时间在每次系统启动的时候会使用，在以后需要的时候会将设置的时间写入到RTC中，别的时候获取时间都通过软件可以获得。 RTC可以使用周期性的中断来产生闹钟，也可以在系统suspend的时候作为系统的唤醒源使用。Linux系统提供了两套RTC接口，/dev/rtc是为pc机器提供，另一种/dev/rtc0, /dev/rtc1支持所有的系统，具体可参考rtc.txt文档。linux为新的接口设计一套驱动模型，如果驱动工程师想增加某一个驱动，只需要将芯片相关的代码编写，然后注册到rtc核心层中即可。
要理解第一个问题，得先从ACPI（高级配置与电源接口）说起，ACPI是一种规范（包含软件与硬件），用来供操作系统应用程序管理所有电源接口。
大家好，我是程栩，一个专注于性能的大厂程序员，分享包括但不限于计算机体系结构、性能优化、云原生的知识。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
云直播
