Harry (Hyeonggon) Yoo
Posts
522Following
98Followers
115- Linux Kernel Developer @ Oracle (Linux Kernel MM) (2025.02 ~ Present)
- Reviewer for the Linux Slab & Reverse Mapping subsystem
- Former Intern @ NVIDIA, SK Hynix, Panmnesia (Security, MM and CXL)
- B.Sc. in Computer Science & Engineering, Chungnam National University (Class of 2025)
Opinions are my own.
My interests are:
Memory Management,
Computer Architecture,
Circuit Design,
Virtualization
Harry (Hyeonggon) Yoo
repeated
repeated
AkaSci 🛰️
AkaSci@fosstodon.org
Edited 1 year ago
NASA is sending a software update to the Voyager 2 spacecraft today!
Data will be sent at 16 bps with a 19 kW transmitter using the 70-m dish at DSN Canberra.
Distance: 20 billion km
Light travel time: 18:40 hours
The patch contains logic to recover from glitches similar to the one in May 2022, when the AACS system on Voyager 1 was sending garbled data. The root cause was not diagnosed. The patch will be activated on Oct 28. Voyager 2 will be next.
https://www.jpl.nasa.gov/news/nasas-voyager-team-focuses-on-software-patch-thrusters
#Voyager
1/n
2
19
2
Harry (Hyeonggon) Yoo
hyeyoo
0
0
3
Harry (Hyeonggon) Yoo
hyeyoo
0
0
2
Harry (Hyeonggon) Yoo
hyeyoo
Edited 1 year ago
https://coverage.kerneltesting.org/slab-experimental-6283c415/mm/
This is a merged LCOV output of my mm & slab test coverage from 30 different kernel configurations.
Looks mostly fine but there are a few small problems:
- Sometimes numbers are inconsistent
- Omission of (some) inline function coverage
This is a merged LCOV output of my mm & slab test coverage from 30 different kernel configurations.
Looks mostly fine but there are a few small problems:
- Sometimes numbers are inconsistent
- Omission of (some) inline function coverage
0
0
1
Harry (Hyeonggon) Yoo
repeated
repeated
Jonathan Corbet
corbet
@marcan @bars One of the worst things about working in the kernel — one of the most toxic parts — is the constant stream of nastiness toward our community that comes from outside.
The kernel community is far from perfect; we have a lot of problems and we have been actively working for years (decades) to improve on them.
We are, nonetheless, a project that manages to incorporate nearly 100,000 commits per year, from over 5,000 developers, into a single code base while maintaining a level of quality that — while also certainly in need of improvement — is good enough for deployment into billions of devices.
As for the use of email...email is painful and broken, but we have found nothing better that will work at the scale we need. See https://lwn.net/Articles/702177/ from a few years back. For all its faults, email is distributed, non-proprietary, scriptable, and gives everybody the freedom to choose their tools; it is a highly inclusive solution in a way that proprietary web forges (for example) are not. Someday we'll find something better and move on with a cry of joy, but that day has not come.
Rather than crapping on the kernel community from afar, why not work with us to try to make things better?
The kernel community is far from perfect; we have a lot of problems and we have been actively working for years (decades) to improve on them.
We are, nonetheless, a project that manages to incorporate nearly 100,000 commits per year, from over 5,000 developers, into a single code base while maintaining a level of quality that — while also certainly in need of improvement — is good enough for deployment into billions of devices.
As for the use of email...email is painful and broken, but we have found nothing better that will work at the scale we need. See https://lwn.net/Articles/702177/ from a few years back. For all its faults, email is distributed, non-proprietary, scriptable, and gives everybody the freedom to choose their tools; it is a highly inclusive solution in a way that proprietary web forges (for example) are not. Someday we'll find something better and move on with a cry of joy, but that day has not come.
Rather than crapping on the kernel community from afar, why not work with us to try to make things better?
7
18
54
@ljs @ptesarik @vbabka
CXL is not feasible for unmovable kernel allocations regardless of latency if the goal is reduction in total memory cost (and thus dynamic capacity change mechanism is used)
BTW the latency is not that bad, it's just like a far and far NUMA node...
ofc emulated CXL is a complete beast - someone recently reported having 500KB/s bandwidth with it ;)
CXL is not feasible for unmovable kernel allocations regardless of latency if the goal is reduction in total memory cost (and thus dynamic capacity change mechanism is used)
BTW the latency is not that bad, it's just like a far and far NUMA node...
ofc emulated CXL is a complete beast - someone recently reported having 500KB/s bandwidth with it ;)
1
0
0
Harry (Hyeonggon) Yoo
hyeyoo
Edited 1 year ago
I need to learn Ansible instead of writing non-portable scripts and memorizing all of them
0
0
1
Oh, tuxmake provides repeatable builds and building in docker containers.
It would be nice solution for parallel GCOV builds
https://tuxmake.org
It would be nice solution for parallel GCOV builds
https://tuxmake.org
0
0
0
1
0
2