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
the moods on facebook/linkedin/fediverse are quite different. everyone seems to be normal on facebook/linkedin, but on fediverse.... hmm :)
1
0
1
Hyeonggon Yoo
hyeyoo
Edited 1 year ago
watching a tutorial on Oppenheimer before going to the cinema
0
0
1
Hyeonggon Yoo
hyeyoo
Edited 1 year ago
Making a small progress on one of my TODOs: run automatic builds & tests using CI tools for MM development kernels
This is a jenkins configuration matrix specially targeting SLUB to cover various SLUB configurations. Only boot test is done atm.
There are many milestones on this project, which demands more time :P
This is a jenkins configuration matrix specially targeting SLUB to cover various SLUB configurations. Only boot test is done atm.
There are many milestones on this project, which demands more time :P
0
0
2
Remotely draining remote PCPs was previously impossible because the only synchronization method was to disable interrupts on !PREEMPT_RT kernels. That's why the patch series changed locking from local_lock to spinlock.
One might wonder the change causes performance regressions due to spinlock overhead but the data shows only minor page fault rate reduction.
Interestingly @vbabka seems to be introducing similar mechanism on the new per-cpu opt-in array in SLUB allocator. BTW SLUB does not support draining other CPUs' per-cpu partial list anyway, I wonder if he would try it as well? (ofc I guess not atm)
One might wonder the change causes performance regressions due to spinlock overhead but the data shows only minor page fault rate reduction.
Interestingly @vbabka seems to be introducing similar mechanism on the new per-cpu opt-in array in SLUB allocator. BTW SLUB does not support draining other CPUs' per-cpu partial list anyway, I wonder if he would try it as well? (ofc I guess not atm)
1
0
1
Hyeonggon Yoo
hyeyoo
Edited 1 year ago
TIL1 - There are three types of scheduling tick reduction mechanism (NO_HZ_FULL, NO_HZ_IDLE, HZ_PERIODIC).
NO_HZ_IDLE reduces scheduling ticks only when a CPU is idle (for energy efficiency). This is the default.
NO_HZ_FULL reduces scheduling ticks when there is only one runnable task per CPU. (used on HPC workloads or realtime applications)
HZ_PERIODIC never reduces scheduling ticks.
TIL2 - The mechnism of the Linux buddy allocator's PCP (per cpu pages) draining was recently changed from interprocessor interrupts, to workqueue, and then remote draining from the CPU that invokes draining. I knew that this exists - but took a closer look during this week's my local kernel study session.
The latest change is quite useful because it does not need to wait for other CPUs to drain their PCP locally, and nohz full CPUs does not need to stop what they were doing and drain their local PCPs.
NO_HZ_IDLE reduces scheduling ticks only when a CPU is idle (for energy efficiency). This is the default.
NO_HZ_FULL reduces scheduling ticks when there is only one runnable task per CPU. (used on HPC workloads or realtime applications)
HZ_PERIODIC never reduces scheduling ticks.
TIL2 - The mechnism of the Linux buddy allocator's PCP (per cpu pages) draining was recently changed from interprocessor interrupts, to workqueue, and then remote draining from the CPU that invokes draining. I knew that this exists - but took a closer look during this week's my local kernel study session.
The latest change is quite useful because it does not need to wait for other CPUs to drain their PCP locally, and nohz full CPUs does not need to stop what they were doing and drain their local PCPs.
1
1
2
Hyeonggon Yoo
hyeyoo
Edited 1 year ago
TIL:
While modern programming languages are specified in context-free or context-sensitive grammars, regular languages are still used for tokenizing the source code because regular language is limited but powerful.
The lexical specification of a typical programming language is written in regular language.
The computational unit that understands regular languages are finite automata. To implement an automaton, a nondeterministic automata that processes a regular expression is created first, and then it is converted to deterministic finite automata for fast processing.
While modern programming languages are specified in context-free or context-sensitive grammars, regular languages are still used for tokenizing the source code because regular language is limited but powerful.
The lexical specification of a typical programming language is written in regular language.
The computational unit that understands regular languages are finite automata. To implement an automaton, a nondeterministic automata that processes a regular expression is created first, and then it is converted to deterministic finite automata for fast processing.
0
0
0
