Battery-Saving Linux Scheduler for Phones

ISEF Category: Systems Software

Subcategory: Languages and Operating Systems  ·  Difficulty: Advanced  ·  Setup: University Lab  ·  Time: Full Year

The Hook

Your phone does not just run apps, it decides where each task should run, and that choice can drain battery fast. A smarter scheduler can act like a traffic cop that sends work to the right CPU lane. If you can predict energy well, you can save power without making the phone feel slow.

What Is It?

A scheduler is the part of an operating system that decides which CPU core runs each task. On a big.LITTLE phone, some cores are fast but power-hungry, while others are slower but cheaper to run. Your project asks a simple question: can the phone guess the energy cost of a task before it runs it, then pick the best core for battery life?

Think of it like packing a backpack for a hike. Heavy gear goes in the right place, or you waste energy carrying it badly. Here, the scheduler can use a tiny model, a small prediction tool trained on app behavior, to estimate how much energy a task might use. If the prediction is good, the phone can choose a better core mix than the default policy.

This topic sits at the intersection of operating systems, mobile performance, and power management. You are not building a new app. You are changing how the phone decides where work should happen, then testing whether that decision lowers battery drain while keeping the device responsive.

Why This Is a Good Topic

This makes a strong science fair topic because you can test it with real measurements, clear baselines, and well-defined outcomes. Battery use, runtime, and responsiveness all give you data you can compare across scheduling policies. The project also connects to a real problem, phones waste energy all the time, and better scheduling can extend battery life without new hardware. You can learn operating system design, benchmarking, data analysis, and model evaluation in one project.

Research Questions

• How does a per-app energy prediction model change battery drain compared with the default scheduler??
• What is the effect of task type, such as video playback, web browsing, or background sync, on prediction error??
• Does a tiny model trained on one app generalize to similar apps with the same workload pattern??
• To what extent do big and LITTLE core assignments change energy use for the same task mix??
• Which feature set best predicts task energy while keeping the model small enough for on-device use??
• How does scheduler choice affect the trade-off between battery drain and app responsiveness??

Basic Materials

• Rooted Android phone with a big.LITTLE CPU architecture, such as a Pixel model that supports low-level testing.
• Laptop or desktop computer for data collection and analysis.
• USB cable for file transfer and device control.
• Power monitor or battery logging app with export support.
• Android debugging tools, such as ADB.
• Spreadsheet software for tabulating results.
• Note-taking app or lab notebook for logging test conditions.

Advanced Materials

• Rooted Android phone with kernel and scheduler access.
• External USB power meter for device-level power measurements.
• Linux workstation for building and flashing test kernels.
• Kernel source tree and cross-compilation toolchain.
• Benchmark suite for mobile workloads.
• Python environment for parsing logs and training a small energy model.
• Thermal monitoring tools for tracking throttling.
• Data logger for CPU frequency, core assignment, and battery state.

Software & Tools

• Python: Cleans logs, builds graphs, and fits small prediction models.
• Jupyter Notebook: Helps you explore scheduler data and compare baseline runs.
• R: Runs statistical tests and makes publication-style plots.
• Android Debug Bridge (ADB): Collects device logs and automates repeated benchmark runs.
• ImageJ: Measures screen-based benchmark outputs when you need frame-level comparisons.

Experiment Steps

1. Define the mobile workload you will compare and the performance metric you care about most.
2. Choose the baseline scheduler policy and the reverse-energy policy you want to test.
3. Decide which device signals, such as CPU load, app type, or frequency state, will feed your energy model.
4. Build a validation plan that compares predicted energy against measured battery drain on repeated runs.
5. Plan controls that keep thermal state, brightness, and network behavior consistent across tests.
6. Set up an analysis method that compares energy savings, runtime, and responsiveness together.

Common Pitfalls

• Testing only one app, which makes the scheduler look better or worse than it really is.
• Mixing warm and cool device runs, which changes battery drain because thermal throttling shifts CPU behavior.
• Using weak battery estimates instead of measured power, which hides the scheduler's true effect.
• Training the energy model on data from one workload and assuming it works for every app pattern.
• Comparing runs with different background activity, which confounds scheduler effects with network and sync noise.

What Makes This Competitive

A strong version of this project goes past a simple before-and-after battery comparison. You need clean baselines, repeatable workloads, and careful control of thermal and background effects. Better entries also test whether the model generalizes across apps, devices, or workload types, not just one case. If you can show a real trade-off curve between energy savings and responsiveness, your project looks much stronger.

Project Variations

• Test the same scheduler idea on tablet workloads instead of phone apps to see whether larger screens and different power states change the result.
• Compare per-app energy models against one global model to find out whether personalization really helps.
• Add thermal throttling data to the scheduler features and test whether prediction improves during long workloads.

Learn More

• MIT OpenCourseWare: Search for operating systems lectures that cover CPU scheduling, process management, and power-aware design.
• Operating Systems: Three Easy Pieces: Free textbook with clear chapters on scheduling and performance, available from the authors' site.
• Android Open Source Project documentation: Search the Android developer and source documentation for power, performance, and scheduler background.
• USENIX papers: Search the USENIX proceedings for research on mobile scheduling, energy-aware operating systems, and big.LITTLE systems.
• PubMed: Search for review articles on mobile power management if you want a biology-style angle on battery and device use patterns.