Kernel - Page Frame 回收
· ☕ 4 分钟
From [Understanding The Linux Kernel]
Page Frame 回收
之前我们了解到,Linux 倾向用最多的内存做 Page Cache。这使我们不得不考虑如何在内存不足前回收内存。问题是,回收内存的程序本身也可能有 IO 操作,也可能需要内存。
寫點東西吧,懒人。
From [Understanding The Linux Kernel]
之前我们了解到,Linux 倾向用最多的内存做 Page Cache。这使我们不得不考虑如何在内存不足前回收内存。问题是,回收内存的程序本身也可能有 IO 操作,也可能需要内存。
page cache 中的每个 page 均归属于文件. 这个文件 — 或更精确来说,是文件的 inode 被称为 page 的owner
.
Page cahce 的核心数据结构是 addrees_space
。一般来说,每个 inode
(Kernel 用来存放文件元信息的内存中的数据结构,可以视为一个文件的描述信息)中包含一个 addrees_space
。
https://tenzir.com/blog/production-debugging-bpftrace-uprobes/
https://shaharmike.com/cpp/vtable-part1/
|
|
$ # compile our code with debug symbols and start debugging using gdb
$ clang++ -std=c++14 -stdlib=libc++ -g main.cpp && gdb ./a.out
...
(gdb) # ask gdb to automatically demangle C++ symbols
(gdb) set print asm-demangle on
(gdb) set print demangle on
(gdb) # set breakpoint at main
(gdb) b main
Breakpoint 1 at 0x4009ac: file main.cpp, line 15.
(gdb) run
Starting program: /home/shmike/cpp/a.out
Breakpoint 1, main () at main.cpp:15
15 Parent p1, p2;
(gdb) # skip to next line
(gdb) n
16 Derived d1, d2;
(gdb) # skip to next line
(gdb) n
18 std::cout << "done" << std::endl;
(gdb) # print p1, p2, d1, d2 - we'll talk about what the output means soon
(gdb) p p1
$1 = {_vptr$Parent = 0x400bb8 <vtable for Parent+16>}
(gdb) p p2
$2 = {_vptr$Parent = 0x400bb8 <vtable for Parent+16>}
(gdb) p d1
$3 = {<Parent> = {_vptr$Parent = 0x400b50 <vtable for Derived+16>}, <No data fields>}
(gdb) p d2
$4 = {<Parent> = {_vptr$Parent = 0x400b50 <vtable for Derived+16>}, <No data fields>}
Here’s what we learned from the above:
Cluster: a logical service with a set of endpoints that Envoy forwards requests to.
Downstream: an entity connecting to Envoy. This may be a local application (in a sidecar model) or a network node. In non-sidecar models, this is a remote client.
Endpoints: network nodes that implement a logical service. They are grouped into clusters. Endpoints in a cluster are upstream
of an Envoy proxy.
Filter: a module in the connection or request processing pipeline providing some aspect of request handling. An analogy from Unix is the composition of small utilities (filters) with Unix pipes (filter chains).
Envoy源码分析之Dispatcher:https://developer.aliyun.com/article/659277
线程相关 Misc:
When handling HTTP/1.1, Envoy will normalize the header keys to be all lowercase. While this is compliant with the HTTP/1.1 spec, in practice this can result in issues when migrating existing systems that might rely on specific header casing.
To support these use cases, Envoy allows configuring a formatting scheme for the headers, which will have Envoy transform the header keys during serialization.
http_protocol_options
.http_protocol_options
in the cluster’s extension_protocol_options
.Currently Envoy supports two mutually exclusive types of header key formatters: