Hyeonggon Yoo
Posts
469Following
90Followers
94- Intern @ NVIDIA Korea (Security System Software) (2024.06 ~)
- 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
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
@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
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
Hyeonggon Yoo
repeated
repeated
Vlastimil Babka
vbabka
A LKML thread meme summary, pure shitposting because SCNR, not meant as an endorsement nor ridicule of any side
Show content
STOP DOING MSEAL()
SYSCALLS WERE NOT SUPPOSED TO BE GIVEN MM_SEAL_ FLAGS
YEARS OF MINMUTABLE() yet NO REAL-WORLD USE FOUND for using more than addr, len PARAMETERS
Wanted not to bother with that anyway to get a break? We had a tool for that: It was called "LD.SO"
"one place honors the sealing, random other places do not" - Statements dreamed up by the utterly Deranged.
LOOK at what Chrome has been demanding your Support for all this time, with all the mprotect(2) permission reduction & OPENBSD_MUTABLE we built for them.
(This is REAL Code, done by REAL Kernel developers).
ON_BEHALF_OF_KERNEL ?????
ON_BEHALF_OF_USERSPACE ???????
VM_SEAL_* -> MM_SEAL_* -> MM_ACTION_* ?????????????????
"Hello, I would like a MM_SEAL_MUNMAP but not MM_SEAL_MMAP VMA please."
They have played us for absolute fools
SYSCALLS WERE NOT SUPPOSED TO BE GIVEN MM_SEAL_ FLAGS
YEARS OF MINMUTABLE() yet NO REAL-WORLD USE FOUND for using more than addr, len PARAMETERS
Wanted not to bother with that anyway to get a break? We had a tool for that: It was called "LD.SO"
"one place honors the sealing, random other places do not" - Statements dreamed up by the utterly Deranged.
LOOK at what Chrome has been demanding your Support for all this time, with all the mprotect(2) permission reduction & OPENBSD_MUTABLE we built for them.
(This is REAL Code, done by REAL Kernel developers).
ON_BEHALF_OF_KERNEL ?????
ON_BEHALF_OF_USERSPACE ???????
VM_SEAL_* -> MM_SEAL_* -> MM_ACTION_* ?????????????????
"Hello, I would like a MM_SEAL_MUNMAP but not MM_SEAL_MMAP VMA please."
They have played us for absolute fools
3
8
21
Hyeonggon Yoo
hyeyoo
Edited 1 year ago
This is how a silently enabled kernel configuration can affect your system performance:
https://lore.kernel.org/stable/97397e8d-f447-4cf7-84a1-070989d0a7fd@amazon.com/T/#u
I fixed this at the beginning of this year, but did not backport to stable trees. Luiz Capitulino from Amazon reported that this resulted in performance regression in their 6.1 kernels.
DEBUG_PREEMPT has been enabled by default since pre-git era for PREEMPT kernels, but distros that were using PREEMPT_VOLUNTARY silently enabled PREEMPTION and DEBUG_PREEMPT after the introduction of PREEMPT_DYNAMIC. And DEBUG_PREEMPT is better disabled for production kernels regardless of the preemption model used.
https://lore.kernel.org/stable/97397e8d-f447-4cf7-84a1-070989d0a7fd@amazon.com/T/#u
I fixed this at the beginning of this year, but did not backport to stable trees. Luiz Capitulino from Amazon reported that this resulted in performance regression in their 6.1 kernels.
DEBUG_PREEMPT has been enabled by default since pre-git era for PREEMPT kernels, but distros that were using PREEMPT_VOLUNTARY silently enabled PREEMPTION and DEBUG_PREEMPT after the introduction of PREEMPT_DYNAMIC. And DEBUG_PREEMPT is better disabled for production kernels regardless of the preemption model used.
0
6
8
Hyeonggon Yoo
hyeyoo
Why are gcov/lcov/genhtml so sensitive to source code path :(
lcov/genhtml requires that there should be source code in the exactly same path of source code in the build machine.
lcov/genhtml requires that there should be source code in the exactly same path of source code in the build machine.
1
0
0