Hyeonggon Yoo
Posts
474Following
89Followers
94- Ex-Intern @ NVIDIA Korea (Security System Software) (2024.06-2024.11)
- Ex-Intern @ Panmneisa (CXL emulation stuff) (~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
In ACPI-compatible OS environment, NUMA node of memory ranges and distance matrix between NUMA nodes are parsed from ACPI SRAT/SLIT tables and they are provided firmware.
ACPI HMAT describes latency/bandwidth characteristics.
CDAT is a set of registers in CXL that reports bandwidth/latency characteristics of CXL devices/switches. it is consumed by firmware to produce HMAT/SRAT tables.
ACPI HMAT describes latency/bandwidth characteristics.
CDAT is a set of registers in CXL that reports bandwidth/latency characteristics of CXL devices/switches. it is consumed by firmware to produce HMAT/SRAT tables.
0
0
1
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
Hyeonggon Yoo
hyeyoo
0
0
3
Hyeonggon Yoo
hyeyoo
0
0
2
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
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
55
