Hyeonggon Yoo
Posts
476Following
91Followers
93- Linux Kernel Developer @ Oracle (Linux Kernel MM) (2025.02 ~ Present)
- Ex-Intern @ SK Hynix (Linux Kernel MM) (2024.12 ~ 2025.01)
- Ex-Intern @ NVIDIA Korea (Security System Software) (2024.06 ~ 2024.11)
- Ex-Intern @ Panmneisa (CXL emulation stuff) (2023.09 ~ 2023.12)
- Undergraduate majoring CSE (estimated graduation: Feb. 2025)
- Working as reviewer at Linux Slab subsystem
- Born in August 6, 2000
Opinions are my own.
My interests are:
Memory Management,
Computer Architecture,
Circuit Design,
Virtualization
Hyeonggon Yoo
hyeyoo
Edited 1 year ago
For quite some time now, I've had two concerns on my career:
The first one is to find a position that allows me to work on (public or internal) kernel stuff, and possibly contribute to the upstream kernel. This is important because I want to work on what I want to.
The other one is to find a position that allows me to observe functional/performance issues on production workloads, fix them and do performance engineering. This is important too because a huge gain on a workload that does not occur in the real world is useless.
I'm not sure if such positions are common and not even sure if they are compatible :/
The first one is to find a position that allows me to work on (public or internal) kernel stuff, and possibly contribute to the upstream kernel. This is important because I want to work on what I want to.
The other one is to find a position that allows me to observe functional/performance issues on production workloads, fix them and do performance engineering. This is important too because a huge gain on a workload that does not occur in the real world is useless.
I'm not sure if such positions are common and not even sure if they are compatible :/
0
0
0
Hyeonggon Yoo
hyeyoo
Edited 1 year ago
Lessons learned today:
- Your theoretical expectation on something is very prone to error and do not believe it even when you are very sure. Prove it by data.
- Do not measure the outcome of multiple changes at once.
- Do not create an account with a very simple password on a publicly available computer, someone will log into it and eat your CPUs.
- Your theoretical expectation on something is very prone to error and do not believe it even when you are very sure. Prove it by data.
- Do not measure the outcome of multiple changes at once.
- Do not create an account with a very simple password on a publicly available computer, someone will log into it and eat your CPUs.
1
0
1
Hyeonggon Yoo
hyeyoo
Edited 1 year ago
When there are no free pages in free list of the requested order, buddy allocator splits a larger page into smaller ones, and allocates a one of the split pages.
TIL: The way buddy splits large pages (and allocating first or last part of a large page) during the expand() function significantly impacts the mergability of the scatter-gather list for IO. The likeliness that pages are allocated in PFN order is important for mergability. This is so subtle and I didn't realize this :(
Consider a scenario where there is only an order 2 block, and four order 0 requests are served. In the diagram above, they are allocated in PFN order, while in the other diagram, they are allocated in the reverse order.
https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=c75b81a5da09be94099cf7b46bdb32fedc8ce71a
And in the history this thing has introduced a regression because the order was not preserved (by mistake) when pages are allocated from PCP lists with __GFP_COLD ;)
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e084b2d95e48b31aa45f9c49ffc6cdae8bdb21d4
TIL: The way buddy splits large pages (and allocating first or last part of a large page) during the expand() function significantly impacts the mergability of the scatter-gather list for IO. The likeliness that pages are allocated in PFN order is important for mergability. This is so subtle and I didn't realize this :(
Consider a scenario where there is only an order 2 block, and four order 0 requests are served. In the diagram above, they are allocated in PFN order, while in the other diagram, they are allocated in the reverse order.
https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=c75b81a5da09be94099cf7b46bdb32fedc8ce71a
And in the history this thing has introduced a regression because the order was not preserved (by mistake) when pages are allocated from PCP lists with __GFP_COLD ;)
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e084b2d95e48b31aa45f9c49ffc6cdae8bdb21d4
0
0
1
@vbabka @AnnaPlusPlus
Sent risky patches that maintainers would not welcome
.....guess I'd better send more
Sent risky patches that maintainers would not welcome
.....guess I'd better send more
1
0
2
Hyeonggon Yoo
repeated
repeated
sj
sj
Edited 1 year ago
DAMON user-space tool (damo) has released[1] its 100th version. A mail[2] for the news, release stats, and appreciation to the DAMON community has also posted. From the mail:
"Looking forward to 200th, and 1,000th release of damo :D We, the community,
will make it together."
[1] https://github.com/awslabs/damo/releases/tag/v1.9.3
[2] https://lore.kernel.org/damon/20230807202044.98700-1-sj@kernel.org/
#linux #kernel #damon #damo
"Looking forward to 200th, and 1,000th release of damo :D We, the community,
will make it together."
[1] https://github.com/awslabs/damo/releases/tag/v1.9.3
[2] https://lore.kernel.org/damon/20230807202044.98700-1-sj@kernel.org/
#linux #kernel #damon #damo
0
2
3
