cpu内核

查看逻辑CPU个数： #cat /proc/cpuinfo |grep "processor"|sort -u|wc -l 24 查看物理CPU个数： #grep "physical id" /proc/cpuinfo|sort -u|wc -l 2 #grep "physical id" /proc/cpuinfo|sort -u physical id : 0 physical id : 1 查看每个物理CPU内核个数： #grep "cpu cores" /proc/cpuinfo|uniq cpu cores : 6 每个物理CPU上逻辑CPU个数： #grep "siblings" /proc/cpuinfo|uniq siblings : 12 判断是否开启了抄超线程： 如果多个逻辑CPU的"physical id"和"core id"均相同，说明开启了超线程 或者换句话说 逻辑CPU个数 > 物理CPU个数 * CPU内核数 开启了超线程 逻辑CPU个数 = 物理CPU个数 * CPU内核数 没有开启超线程 一次性查询所有信息： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 #!/bin/bash physicalNumber=0 coreNumber=0 logicalNumber=0 HTNumber=0

一、分段单元 1、index 指定放在GDT或者LDT相应的段描述符入口 2、TI 指明段描述符在GDT（TI=0）或者LDT（TI=1） 3、RPL 请求者特权级，当相应的段选择符装入到CS寄存器中指示出CPU当前的特权级 二、GDT 1、单核只有一个GDT,多核每个 CPU对应一个GDT,所有GDT存放在cpu_gdt_table数组中， GDT地址和大小存放在cpu_gdt_descr数组中。 2、GDT包含18个段描述符和14个空的，未使用的，或保留的项。 [1]、18个段描述段 （1）、用户态和内核态下的代码段和数据段共4个。 （2）、任务状态段（TSS），每个处理器一个。存放在init_tss数组中。 （3）、一个包括缺省局部描述符表的段。（所有共享进程段） （4）、3个局部线程存储段。 （5）、与高级电源管理（AMP）相关的3个段。 （6）、与支持即插即用（PnP）功能的BIOS服务程序相关的5个段。 （7）、被内核用于处理“双重错误”异常的特殊TSS段。 来源： https://www.cnblogs.com/fantom/archive/2013/03/14/2958666.html

什么是内存分页？ 我们知道，CPU是通过寻址来访问内存的。32位CPU的寻址宽度是 0~0xFFFFFFFF ，16^8 计算后得到的大小是4G，也就是说可支持的物理内存最大是4G。 但在实践过程中，碰到了这样的问题，程序需要使用4G内存，而可用物理内存小于4G，导致程序不得不降低内存占用。 为了解决此类问题，现代CPU引入了 MMU（Memory Management Unit 内存管理单元）。 MMU 的核心思想是利用虚拟地址替代物理地址，即CPU寻址时使用虚址，由 MMU 负责将虚址映射为物理地址。 MMU的引入，解决了对物理内存的限制，对程序来说，就像自己在使用4G内存一样。 内存分页(Paging)是在使用MMU的基础上，提出的一种内存管理机制。它将虚拟地址和物理地址按固定大小（4K）分割成页(page)和页帧(page frame)，并保证页与页帧的大小相同。 这种机制，从数据结构上，保证了访问内存的高效，并使OS能支持非连续性的内存分配。 在程序内存不够用时，还可以将不常用的物理内存页转移到其他存储设备上，比如磁盘，这就是大家耳熟能详的虚拟内存。 在上文中提到，虚拟地址与物理地址需要通过映射，才能使CPU正常工作。 而映射就需要存储映射表。在现代CPU架构中，映射关系通常被存储在物理内存上一个被称之为页表(page table)的地方。 如下图： 从这张图中

一、cpu 详解 CPU 按照指令集可以分为精简指令集 CPU 和复杂指令集 CPU 两种，区别在于前者的指令集精简，每个指令的运行时间都很短，完成的动作也很单纯，指令的执行效能较佳；但是若要做复杂的事情，就要由多个指令来完成。后者的指令集每个小指令可以执行一些较低阶的硬件操作，指令数目多而且复杂，每条指令的长度并不相同。因为指令执行较为复杂所以每条指令花费的时间较长，但每条个别指令可以处理的工作较为丰富。 1、x86-64的含义 x86： 是针对 CPU 的型号或者说架构的一种统称 。 64 位： CPU 的位数指的是 CPU 一次性能从内存中取出多少位二进制指令 ，64bit 指的是一次性能从内存中取出 64 位二进制指令 。 CPU具有向下兼容性:64位的CPU 既能运行 32 位的程序也能运行 64 位的程序 2 、 内核态与用户态（ 代表 cpu 的两种工作状态 ） （1）内核态：运行的程序是操作系统，可以操作计算机硬件 （2）用户态：运行的程序是应用程序，不能操作计算机硬件 内核态与用户态的转换： 应用程序的运行必然涉及到计算机硬件的操作，那就必须有用户态切换到内核态下才能实现，所以计算机工作时在频繁发生内核态与用户态的转换。 3 、多线程与多核芯片 （1）2 核 4 线程 （ 假 4 核 ） ： 2 核代表有两个 cpu ， 4 线程指的是每个 cpu 都有两个线程

CentOS内核，对应的文件是/proc/sys/kernel/watchdog_thresh。CentOS内核和标准内核还有一个地方不一样，就是处理CPU占用时间过长的函数，CentOS下是watchdog_timer_fn()函数。 如果你的内核是标准内核的话，可以通过修改/proc/sys/kernel/softlockup_thresh来修改超时的阈值 参考文献:https://zhidao.baidu.com/question/1829924822713415300.html 首先，这条信息可以输出，说明即使发生死锁或者死循环，还是有代码可以执行。第二，可以通过这个日志信息，找到对应的处理函数，这个函数所在的模块就是用来处理CPU被过度使用时用到的。所以通过这个事情，可以看到内核打印出的只言片语都有可能成为你解决问题的关键，一定要从重视这些信息，从中找出有用的东西。 我经常看的内核版本是官方的2.6.32内核，这个版本中我找到的函数是softlockup_tick()，这个函数在时钟中断的处理函数run_local_timers()中调用。这个函数会首先检查watchdog线程是否被挂起，如果不是watchdog线程，会检查当前占有CPU的线程占有的时间是否超过系统配置的阈值，即softlockup_thresh。如果当前占有CPU的时间过长

近期在服务器跑大量高负载程序，造成cpu soft lockup。如果确认不是软件的问题。 解决办法: #追加到配置文件中 echo 30 > /proc/sys/kernel/watchdog_thresh #查看 [root@git-node1 data]# tail -1 /proc/sys/kernel/watchdog_thresh 30 #临时生效 sysctl -w kernel.watchdog_thresh=30 #内核软死锁（soft lockup）bug原因分析 Soft lockup名称解释：所谓，soft lockup就是说，这个bug没有让系统彻底死机，但是若干个进程（或者kernel thread）被锁死在了某个状态（一般在内核区域），很多情况下这个是由于内核锁的使用的问题。 vi /etc/sysctl.confkernel.watchdog_thresh=30 参考文章： CentOS内核，对应的文件是/proc/sys/kernel/watchdog_thresh。CentOS内核和标准内核还有一个地方不一样，就是处理CPU占用时间过长的函数，CentOS下是watchdog_timer_fn()函数。 如果你的内核是标准内核的话，可以通过修改/proc/sys/kernel/softlockup_thresh来修改超时的阈值 参考文献

线上centos6出现软死锁 kernel:BUG: soft lockup 今天线上一台centos6机器用xshell一直连接不上，然后在xshell上显示 Message from syslogd@GZxxx at Mar 29 14:13:14 ... kernel:BUG: soft lockup - CPU#1 stuck for 68s! [events/1:36] 过了10分钟，终于可以连上了，看一下开机日志 dmesg |grep stuck BUG: soft lockup - CPU#2 stuck for 67s! [vmmemctl:894] BUG: soft lockup - CPU#5 stuck for 67s! [bdi-default:49] BUG: soft lockup - CPU#3 stuck for 67s! [irqbalance:1351] BUG: soft lockup - CPU#4 stuck for 67s! [swapper:0] BUG: soft lockup - CPU#6 stuck for 67s! [watchdog/6:30] BUG: soft lockup - CPU#5 stuck for 67s! [vmmemctl:894] BUG: soft lockup - CPU#0 stuck for

VMware中CPU分配不合理以及License限制引起的SQL Scheduler不能用于查询处理 https://www.cnblogs.com/kerrycode/p/6101018.html 有一台SQL Server（SQL Server 2014 标准版）服务器中的scheduler_count与cpu_count不一致，如下截图所示： SELECT cpu_count , scheduler_count FROM sys.dm_os_sys_info; SQL Server中Scheduler数量应该与逻辑CPU的核数一致，而sys.dm_os_sys_info中的scheduler_count 为8，少于cpu_count的12个数量，那么很有可能，有一些Scheduler的状态为VISIBLE ONLINE.下面摘自 Healthy SQL: A Comprehensive Guide to Healthy SQL Server Performance SELECT is_online ,[status] , COUNT(*) AS [count] FROM sys.dm_os_schedulers WHERE scheduler_id < 255 GROUP BY is_online, [status]; 官方文档 https://msdn.microsoft

原创作品转载请注明出处 原创作者 ShenYue(沈乐) 实验日期 20160306 实验名称 完成一个简单的时间片轮转多道程序内核代码 实验来源 《 Linux 内核分析》 MOOC 课程 http://mooc.study.163.com/course/USTC-1000029000 操作系统单程序的函数调用使用的是 堆栈机制 , 通过 ebp esp eip 指针的进栈出栈来切换不同的栈帧 ( 执行上下文 ), 然而单 CPU 只能有唯一的执行流 , 多进程环境中不可能让单一进程 ” 独占 ” , 如何实现多进程并行工作 , 在其他进程使用 CPU 的时候可以 ” 抢占 ” 执行资源 ? 答案就是 interrupt( 中断机制 ). 下面是一个关于 时间片轮转的操作系统内核实验 , 由于 Linux 内核代码本身提供了预留的接口用于开发者定义自己的系统启动函数和时钟中断处理函数 , 所以简单地实际这样的函数来进行中断处理动作就可以模拟周期性地时间中断 ” 抢占 ” 系统启动进程的过程 . 登录实验楼的环境 , 其中已经事先安装好了 GCC 的运行环境 ,QEMU 硬件模拟环境和 Linux 内核编译源码 . 定义 my_start_kernel, 周期性地在内核态打印 my_start_kernel here 的字符串 . 定义timer interrupt的回调函数my

朋友，你有没有过关于做一个OS的疯狂想法呢？ 我的确有过——在6年以前，读高中的时候。当时每天被Windows95的蓝屏折磨得要命，甚至已经厌烦了一周就要重装一次系统的生活。（呵呵，没办法，当时特别喜欢下载各种新奇的软件玩……结果经常导致系统越来越乱，最后蓝屏不断）另一方面，当时因为对DOS系统已经玩了两三年，自我感觉良好，中断之类的也算熟悉，没事写个TSR之类的小东西，就自以为已经了解操作系统了。所以经常想，Windows这么差，那些电脑高手们干嘛不联合起来，写一个更好的操作系统呢？甚至可以采用稳定安全的Linux内核，让其兼容Win32/DOS的程序不就是了？ 然后就正好有了这么一个事情发生：99年5月7日美国轰炸了中国驻 贝尔格莱德大使馆。当时愤慨的中国人中，有人开办了一个网站，就是关于建立中国自己的OS的。网站上的慷慨言辞我已经忘记了；只记得该网站正在召集许多电脑高手，要开发中国自己的OS，再也不用M$的产品了。甚至还拿出了一个用C编写的“进入保护模式”的程序。可见，他们的设想是不基于Linux等任何已有操作系统，硬生生的从内核到Shell，开发一个全新的操作系统。 最后的事实证明，他们好像没有成功。 接着，随着Windows2000，XP相继推出，Windows越来越稳定，尤其在XP上已经很难得见到当年的“蓝屏”了；甚至可以说，XP下遇到蓝屏多半是硬件故障