本文是A leap year check in three instructions的翻译，前两天在HackerNews上看到这篇文章，闰年的判断方法，从一开始学编程就是一个经典的练习题，但是深挖下去，作者只用了三条指令就能实现闰年的判断，感觉还挺有意思的，所以就翻译分享一下。
省流不看版（基于DeepSeek总结）：
文章介绍了一种使用大约3个CPU指令实现快速闰年检查的方法。这种方法不同于标准算法（涉及模运算和分支），而是利用位操作和魔法数字，将闰年规则（能被4整除，但不能被100整除，除非能被400整除）巧妙地映射到对年份乘以一个常数后的结果进行位范围检查。这种位操作方法对于随机年份输入表现出显著的速度提升，并且针对特定范围已证明是最优解。这项优化技术涉及复杂的位运算细节。
以下是原文的翻译：
近期线上出现了一个问题，现象是有一台机器，网络出现了不定时的延迟：
# ping -i 0.05 192.168.0.5
#...
64 bytes from 192.168.0.5: icmp_seq=673 ttl=63 time=0.203 ms
64 bytes from 192.168.0.5: icmp_seq=674 ttl=63 time=0.210 ms
64 bytes from 192.168.0.5: icmp_seq=675 ttl=63 time=0.218 ms
64 bytes from 192.168.0.5: icmp_seq=676 ttl=63 time=0.233 ms
64 bytes from 192.168.0.5: icmp_seq=677 ttl=63 time=406 ms
64 bytes from 192.168.0.5: icmp_seq=678 ttl=63 time=354 ms
64 bytes from 192.168.0.5: icmp_seq=679 ttl=63 time=302 ms
64 bytes from 192.168.0.5: icmp_seq=680 ttl=63 time=251 ms
64 bytes from 192.168.0.5: icmp_seq=681 ttl=63 time=199 ms
64 bytes from 192.168.0.5: icmp_seq=682 ttl=63 time=147 ms
64 bytes from 192.168.0.5: icmp_seq=683 ttl=63 time=94.8 ms
64 bytes from 192.168.0.5: icmp_seq=684 ttl=63 time=43.0 ms
64 bytes from 192.168.0.5: icmp_seq=685 ttl=63 time=0.216 ms
64 bytes from 192.168.0.5: icmp_seq=686 ttl=63 time=0.248 ms
#...以50ms为间隔ping，发现概率性的会出现超过400ms的延迟，但是并没有丢包的现象发生。
最近接到一个客户反馈，说他们的机器，遇到了top命令中，hardirq的值特别高的问题。
top - 15:27:37 up 43 days, 3:42, 1 user, load average: 44.75, 53.47, 51.66
Tasks: 244 total, 1 running, 243 sleeping, 0 stopped, 0 zombie
%Cpu0 : 10.3 us, 19.8 sy, 0.0 ni, 39.7 id, 0.4 wa, 28.2 hi, 1.6 si, 0.0 st
%Cpu1 : 10.7 us, 21.3 sy, 0.0 ni, 40.7 id, 0.4 wa, 26.1 hi, 0.8 si, 0.0 st
%Cpu2 : 10.0 us, 19.1 sy, 0.0 ni, 41.4 id, 0.4 wa, 27.9 hi, 1.2 si, 0.0 st
%Cpu3 : 10.4 us, 20.7 sy, 0.0 ni, 40.2 id, 0.4 wa, 26.7 hi, 1.6 si, 0.0 st
%Cpu4 : 10.4 us, 15.5 sy, 0.0 ni, 45.4 id, 0.4 wa, 28.3 hi, 0.0 si, 0.0 st
%Cpu5 : 10.8 us, 21.9 sy, 0.0 ni, 39.4 id, 0.4 wa, 27.1 hi, 0.4 si, 0.0 st
%Cpu6 : 10.1 us, 18.6 sy, 0.0 ni, 41.7 id, 0.4 wa, 28.7 hi, 0.4 si, 0.0 st
%Cpu7 : 10.6 us, 25.2 sy, 0.0 ni, 36.6 id, 0.0 wa, 26.4 hi, 1.2 si, 0.0 st从top命令输出可以看到，hardirq的值特别高，超过了25%。这导致了idle的下降，触发了监控的频繁报警。
最近线上出现一些VM网卡收包队列不均匀的问题，即使是将网卡队列中断均匀的绑定到各个CPU上，依然会出现某个核特别高的情况：
%Cpu0 : 0.0 us, 0.0 sy, 0.0 ni, 98.3 id, 0.0 wa, 0.9 hi, 0.9 si, 0.0 st
%Cpu1 : 0.0 us, 0.0 sy, 0.0 ni, 97.5 id, 0.0 wa, 0.8 hi, 1.7 si, 0.0 st
%Cpu2 : 0.0 us, 0.0 sy, 0.0 ni, 99.1 id, 0.0 wa, 0.0 hi, 0.9 si, 0.0 st
%Cpu3 : 0.9 us, 0.0 sy, 0.0 ni, 98.3 id, 0.0 wa, 0.0 hi, 0.9 si, 0.0 st
%Cpu4 : 0.0 us, 0.0 sy, 0.0 ni, 98.3 id, 0.0 wa, 0.0 hi, 1.7 si, 0.0 st
%Cpu5 : 0.0 us, 0.0 sy, 0.0 ni, 97.4 id, 0.0 wa, 0.9 hi, 1.7 si, 0.0 st
%Cpu6 : 0.0 us, 0.0 sy, 0.0 ni, 97.4 id, 0.0 wa, 0.9 hi, 1.7 si, 0.0 st
%Cpu7 : 0.0 us, 0.0 sy, 0.0 ni, 98.3 id, 0.0 wa, 0.0 hi, 1.7 si, 0.0 st
%Cpu8 : 0.0 us, 0.0 sy, 0.0 ni, 46.3 id, 0.0 wa, 3.4 hi, 50.3 si, 0.0 st
%Cpu9 : 0.0 us, 0.0 sy, 0.0 ni, 97.4 id, 0.0 wa, 0.9 hi, 1.7 si, 0.0 st
%Cpu10 : 0.0 us, 0.0 sy, 0.0 ni, 98.3 id, 0.0 wa, 0.0 hi, 1.7 si, 0.0 st
%Cpu11 : 0.0 us, 0.0 sy, 0.0 ni, 99.1 id, 0.0 wa, 0.0 hi, 0.9 si, 0.0 st
%Cpu12 : 0.0 us, 0.0 sy, 0.0 ni, 98.3 id, 0.0 wa, 0.0 hi, 1.7 si, 0.0 st
%Cpu13 : 0.0 us, 0.0 sy, 0.0 ni, 99.1 id, 0.0 wa, 0.0 hi, 0.9 si, 0.0 st
%Cpu14 : 0.0 us, 0.0 sy, 0.0 ni, 98.3 id, 0.0 wa, 0.0 hi, 1.7 si, 0.0 st
%Cpu15 : 0.0 us, 0.0 sy, 0.0 ni, 98.3 id, 0.0 wa, 0.0 hi, 1.7 si, 0.0 st能看到其他核大部分还是比较均匀的，就是cpu8确实比其他核高很多。经过了一些排查，发现和VM使用了IPIP Tunnel有关。
上一篇x86平台的TSC（TIME-STAMP COUNTER）中大概分析了一下TSC的一些相关的特性，以及TSC作为系统时钟源的一些基础条件。那么，在虚拟化的场景下，如何让Guest也用上TSC呢？这篇文章就来讨论一下TSC在KVM虚拟化中的使用。
默认情况下，KVM虚拟机首选的时钟源是kvm-clock，即使将VM的CPU Model设置为host-passthrough，也不会使用TSC作为时钟源。
# lscpu|grep Flags
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq dtes64 vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves wbnoinvd arat vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq la57 rdpid fsrm md_clear flush_l1d arch_capabilities
# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
kvm-clock acpi_pm
# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
kvm-clock今天跟着Intel的开发手册，看看如何随着Intel对TSC不断的修改和增加新特性，让TSC从一个简单的性能计数器发展成当前Linux上x86平台最重要的时钟源之一。本文基本上可以看作是Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3B: System Programming Guide, Part 2中17.15 TIME-STAMP COUNTER这章的翻译和总结。
在x86平台上，Linux系统里最常用的一个时钟源就是tsc，具体的，可以通过命令查看当前的时钟源和系统里可用的时钟源：
# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm
# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc那么TSC是个什么东西呢？我们可以跟着手册看一看。
首先需要解释一下标题，原谅我当了一回标题党，此UFO不是Unidentified flying object，而是在网络中的一个Oflload卸载技术UDP fragmentation offload。事情的起因是这样的，我们最近尝试将线上的虚拟机，从基于网卡SR-IOV+直通的方案，切换到基于DPDK+vhost-user的方案，以换取热迁移的效率提升。
从之前的模拟压测和线上灰度效果来看，新的DPDK方案的性能和稳定性都处于很好的水平，在我们的场景下可以很好地满足需求。
直到灰度到某个业务的时候，发生了一些问题，导致了虚拟机的网络中断。
在之前的好几篇Blog里，都使用了火焰图来对业务进行性能优化，之前为了抓取火焰图，需要用到好几个工具进行组合，流程还是比较麻烦的。随着RHEL的版本更新，Redhat提供了一个更简单快速的方法实现了一键抓取火焰图的功能。
对于比较了解云计算的人来说，一定接触过AWS、阿里云的API接口，这两者的API调用方式很相似，当然具体谁参考谁这里就不深究了。以给EC2/ECS添加Tag这个接口为例：
AWS:
https://ec2.amazonaws.com/?Action=CreateTags
&ResourceId.1=ami-1a2b3c4d
&ResourceId.2=i-1234567890abcdef0
&Tag.1.Key=webserver
&Tag.1.Value=
&Tag.2.Key=stack
&Tag.2.Value=Production
&AUTHPARAMS阿里云：
https://ecs.aliyuncs.com/?Action=TagResources
&RegionId=cn-hangzhou
&ResourceId.1=i-bp1j6qtvdm8w0z1o0****
&ResourceId.2=i-bp1j6qtvdm8w0z1oP****
&ResourceType=instance
&Tag.1.Key=TestKey
&Tag.1.Value=TestKey
&<公共请求参数>接上篇LSI RAID卡芯片和各个OEM对应卡型号列表里说的后续DIY NAS的想法，经过快3个月的时间，终于来更新整个DIY过程了，总结起来在整个过程中，收获的主要还是折腾的乐趣，要说折腾的尽头是白群晖，随着时间的推移，个人还是比较认同的，不过不得不说白群晖确实太贵了，都说群晖是买软件送硬件，但是这软件也太贵了点。