Differences between revisions 1 and 2
Revision 1 as of 2024-05-22T13:19:51+0000
Size: 3557
Editor: Markovlaic
Comment:
Revision 2 as of 2024-06-17T21:42:45+0000
Size: 3586
Editor: Markovlaic
Comment:
Deletions are marked like this. Additions are marked like this.
Line 50: Line 50:
[[attachment:proposal.pdf]]

Project name

Project description

It is common for kernel subsystems to conditionally include functionality, based on compile time and runtime configurations which are relatively infrequently subject to change. Typical examples include: toggling of DTrace probes, boot- time optimizations based on hardware capabilities and inclusion of additional security checks. This is often done by examining the state of a global flag and executing a block of code conditionally based on that state. When this is done in a ”hot” (i.e. frequently executed) code path, the overhead of the conditional execution can become significant. Moreover, in situations in which the state of the inspected flags changes rarely, most of the performed checks are redundant. The primary goal of this project is to design and implement a low overhead mechanism for conditional execution in contexts in which the branching condition does not change often. The mechanism will be based on runtime code patching of instructions. The second major goal is applying the developed mechanism to an existing block of kernel code. The current working name for the interface is zcond.

Deliverables

  • A patch implementing the code patching and static branching mechanism for the x86-64 architecture
  • A patch which applies the developed mechanism to an existing piece of kernel code

Milestones

(5-10 milestones, with dates, indicating when you hope or expect to be able to complete features. This section is mandatory. Please negotiate these with your mentor to make sure you're not under- or over-estimating the amount of work to be done. Please also make sure the following four dates are included within your milestones)

  • May 13th - May 19th: Start working on static branch selection
    • Implement the DEFINE_ZCOND_TRUE() and DEFINE_ZCOND_FALSE() macros

    • Implement rudimentary versions of zcond_true() and zcond_false() functions

  • May 20th - May 26th: Continue working on the static branch selection
    • Finish the implemention of zcond_true() and zcond_false() functions, utilizing the asm goto directive.

  • May 27th - June 2nd: Finish work on the static branch selection
    • Perform some rudimentary testing
    • Begin researching the mechanisms needed to support code patching
  • July 3rd - July 9th: Start working on the code patching
    • Start work on the single-processor versions of void zcond_enable() and zcond_disable() functions.

  • July 1st - July 7th: finish working on the single processor version of code patching
    • start researching the locking mechansims needed for an SMP version of the code patching mechansim
  • July 8th - July 21st: mplement the SMP version of the code patching mechanism
  • July 22nd - July 28th
    • Work out any remaining issues
    • Benchmark the mechanism with an artificial test suite
    • Start looking for kernel code suitable to be refactored to use the new interface
  • July 29th - August 4th
    • Study the existing kernel code selected for refactoring
    • Rewrite the selected piece of the kernel
  • August 5th - August 11th: Final code review with my mentor
  • August 12th - August 19th:
    • Work out remaining issues
    • Work on documentation

The Code

Github

linux static keys proposal.pdf

SummerOfCode2024Projects/ZeroCostConditionalExecutionMechanism (last edited 2024-06-17T21:42:45+0000 by Markovlaic)