Harry (Hyeonggon) Yoo
Posts
566Following
104Followers
116- 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
@ljs
Thanks! I'm proud of how far I've come ;) just going to keep going.
my PT has successfully gaslighted me, like, 'getting lean is better than eating pizza and chicken" yeah sure sure
Thanks! I'm proud of how far I've come ;) just going to keep going.
my PT has successfully gaslighted me, like, 'getting lean is better than eating pizza and chicken" yeah sure sure
0
0
1
Harry (Hyeonggon) Yoo
hyeyoo
Edited 2 months ago
Here’s a progress update on my diet! It’s been five weeks now.
- Five workout sessions per week (focusing on losing fat)
- Eating only 2 sandwiches per day (most of the time!)
Target weight is about 70-75kg... so still a long long way to go.
- Five workout sessions per week (focusing on losing fat)
- Eating only 2 sandwiches per day (most of the time!)
Target weight is about 70-75kg... so still a long long way to go.
1
0
4
Harry (Hyeonggon) Yoo
repeated
repeated
Marco Elver
melver@fosstodon.orgPrototype for type-based partitioning of Linux kernel slab caches: https://discourse.llvm.org/t/rfc-a-framework-for-allocator-partitioning-hints/87434/24?u=melver
Compiler seems to be doing a good-enough job of inferring allocated types per /proc/slabinfo. With the diagnostic -Rpass=alloc-token I can see about 965 allocation sites where it failed to infer the allocated type, but most of them are "bag of bytes", and only few with complex sizeof calculations like struct_size that are too opaque right now (but can be fixed).
2
3
1
Harry (Hyeonggon) Yoo
hyeyoo
Edited 2 months ago
Working on saving 8 or 16 bytes per slab object in certain slab caches that fall into special cases, most notably 0.7%-0.8% or 1.5%-1.6% (depending on the configuration) memory savings for the inode cache (ext4 and xfs).
When memory cgroup and memory allocation profiling are enabled (the former being very common in production and the latter less so), the kernel allocates two pointers per object: one for the memory cgroup to which it belongs, and another for the code location that requested the allocation.
In two special cases, this overhead can be eliminated by allocating slabobj_ext metadata from unused space within a slab page:
- Case 1. The "leftover" space after the last slab object is larger than the size of an array of slabobj_ext.
- Case 2. The per-object alignment padding is larger than sizeof(struct slabobj_ext).
Thanks to @vbabka who suggested an excellent general approach to cover Case 1 and 2 with a minimal performance impact on the memory cgroup charging code (more details in the cover letter)
For these two cases, one or two pointers can be saved per slab object. Examples include the ext4 inode cache (case 1) and the xfs inode cache (case 2). That results in approximately 0.7-0.8% (memcg) or 1.5-1.6% (memcg + mem profiling) of the total inode cache size.
https://lore.kernel.org/linux-mm/20250827113726.707801-1-harry.yoo@oracle.com/
When memory cgroup and memory allocation profiling are enabled (the former being very common in production and the latter less so), the kernel allocates two pointers per object: one for the memory cgroup to which it belongs, and another for the code location that requested the allocation.
In two special cases, this overhead can be eliminated by allocating slabobj_ext metadata from unused space within a slab page:
- Case 1. The "leftover" space after the last slab object is larger than the size of an array of slabobj_ext.
- Case 2. The per-object alignment padding is larger than sizeof(struct slabobj_ext).
Thanks to @vbabka who suggested an excellent general approach to cover Case 1 and 2 with a minimal performance impact on the memory cgroup charging code (more details in the cover letter)
For these two cases, one or two pointers can be saved per slab object. Examples include the ext4 inode cache (case 1) and the xfs inode cache (case 2). That results in approximately 0.7-0.8% (memcg) or 1.5-1.6% (memcg + mem profiling) of the total inode cache size.
https://lore.kernel.org/linux-mm/20250827113726.707801-1-harry.yoo@oracle.com/
0
1
2
Harry (Hyeonggon) Yoo
hyeyoo
0
0
2
Harry (Hyeonggon) Yoo
repeated
repeated
Harry (Hyeonggon) Yoo
hyeyoo
I didn't really work on my legs much before, but ever since I started PT, my legs hurt with every move I make
0
0
1
Harry (Hyeonggon) Yoo
hyeyoo
First day of PT, quite tired.
…now my trainer says only two sandwiches are allowed every day. Oh no!
…now my trainer says only two sandwiches are allowed every day. Oh no!
0
0
2
Harry (Hyeonggon) Yoo
repeated
repeated
Jonathan Corbet
corbet
For a while now, the kernel's configuration and build systems have been an area of concern for me. Almost nobody truly understands those complex subsystems, which were handled by a single maintainer.
That maintainer, Masahiro Yamada, has just stepped down after eight years on the job:
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8d6841d5cb20
Happily, Nathan Chancellor and Nicolas Schier have agreed to pick up the build system. The configuration system, instead, is now unmaintained. That ... seems less than optimal.
Thanks to Masahiro for doing this work all these years, and to Nathan and Nicolas for stepping up!
That maintainer, Masahiro Yamada, has just stepped down after eight years on the job:
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8d6841d5cb20
Happily, Nathan Chancellor and Nicolas Schier have agreed to pick up the build system. The configuration system, instead, is now unmaintained. That ... seems less than optimal.
Thanks to Masahiro for doing this work all these years, and to Nathan and Nicolas for stepping up!
4
22
51