从低延迟到高吞吐：两种处理器组织“时间”的不同方式。 大白话说：CPU 在一条指令流后面找活，GPU 在许多 Warp 之间换一个能跑的。 一条加载指令迟迟不返回，CPU 和 GPU 都不能凭空造出结果。它们只能在等待期间找别的工作。真正的差别在于去哪里找：CPU 沿着当前线程继续向后找，GPU 则从已经驻留的其他 Warp 中换一个。 我最初理解 GPU Scoreboard 时，总想先弄清楚它

接着调试gnu动态链接器，又没带原来的电脑，不想花时间重新编译glibc。了解到linux提供了带debug-symbol的libc：libc-dbg，可以直接调试。apt install libc-dbg安装后一看（笔者当时这台电脑的系统是ubuntu，遂用dpkg -L libc6-dbg），发现目录下并未找到ld和libc等文件，apt update后，还是没找到。遂apt download

include/linux/page_ref.h: page_ref_count用来检测每个page正被多少个进程引用 do_wp_page->wp_can_reuse_anon_folio->folio_ref_count folio如果某个函数收到参数是一个指向了 tail page 的 page structure，那么这个函数是应该针对这个 tail pag

动态链接相关结构Auxiliary vector简介我们知道动态链接的程序的加载过程分成如下三步 内核加载动态链接器ld.so，并为可执行文件创建相关进程，设置好进程的部分信息 内核将控制权限交给动态链接器，动态链接器加载应用程序以及其需要使用到的动态库 程序加载完后，控制权限交给可执行文件 在第二步中，动态链接器需要知道可执行文件和本进程的一些辅助信息，例如动态链接器最后需要将控制权限交给可

记录一下阅读memcpy/memcmp/memmove时碰到的一些问题 memcmp在plain版本中，copy 大块会调用__vm_copy函数按页为单位进行拷贝。此时只是将页面设置为copy on write，待目的地址被写入数据时，才会调用copy_page函数按页面为单位进行数据copy。copy_page的实现如下。 x86位置：linux/arch

虚函数表虚函数表的结构很容易找到文档，参考 查表过程疑问虚函数表中存着一个个最终动态确定下来的虚函数的地址，在调用虚函数的时候，是如何在虚函数表中找到当前调用这个函数的地址的？ 网上的回答编译器遇到一个虚函数定义的时候就记住一个名字，遇到一个虚函数调用的时候也记住一个名字，编译完成后，一个一个统计每个类的虚表里应该有多少个虚函数，然后把统计到的虚函数一个一个分配到格子里，得到一个名字到偏移的对应关

why最近被问到了一个之前没思考过的问题。memcpy这类内存函数总所周知是cpu-feature bound的，即memcpy会根据cpu特性的实现多个版本。例如各个cpu支持的向量指令不同。现在问题来了，每一次调用memcpy时都要先通过cpuid或者xgetbv等指令先检测支持的指令集，再选择采用哪个版本吗？如果memcpy的数据量较大，那么检测时间或许可以忽略不计，但是数据量较小时就不能忍

链接器在linux中，链接器分为 动态链接器：ld-linux.so，路径一般为/lib/i386-linux-gnu/ld-2.31.so 静态链接器：ld，路径一般为/usr/bin/x86_64-linux-gnu-ld.bfd 静态链接器x86_64-linux-gnu-ld.bfd名字中的bfd是什么？ 总所周知，linux

api数据结构定义好了，逻辑实现具体是如何驱动这些数据结构的呢？使用上，大体分为准备、提交、收割过程。 linux kernel仅仅提供了三个系统调用，简化了异步io的操作 12345678910// 初始化一个新的 io_uring 上下文，注册io_uring实例，包括注册共享内存等int io_uring_setup(u32 entries, struct io_uring_params *

动机探索scylladb因高效io带来的极速性能，然而并未用上io_uring这一技术。不过无所谓了，如果io_uring在其执行框架seastar前提出，应该就被用上了。 资料 Efficient IO with io_uring What’s new with io_uring Ringing in a new asynchronous I/O API liburing 操作