5

I'm trying to find a way to demonstrate how different schedulers may affect the runtime of a program. So far, I'm only using the time function on linux to try and see measurable differences using noop, CFS, and deadline schedulers but I'm not having any luck. For the test programs, I just wrote a bunch of C programs that basically loop and count numbers.

I thought that maybe if I start one process that counts to a higher number, and then start a second process that doesn't count quite as high; using the deadline scheduler, the second process may finish significantly faster because it's a less resource-intensive job. However, I don't see any difference at all between schedulers. I'm wondering if maybe my understanding of schedulers is a little flawed? Is there a more appropriate type of program I could try making to demonstrate some of these concepts?

Can anyone give me some tips, advice, or anything like that?

Leggy
  • 147
  • 7
  • Nice question! Aren't there any benchmarks available? Don't reinvent the wheel, and use one of these. Maybe look for some scientific papers about schedulers, and check the benchmarks they ve used to measure them. – sestus Jun 18 '14 at 06:44
  • Why don't you use `hackbench` or some other benchmarking tools. Or for custom programs, [https://github.com/tsuna/contextswitch](https://github.com/tsuna/contextswitch) is a good starting point. – Sanket Parmar Jun 18 '14 at 06:56

1 Answers1

1

While poking around Con Kolivas code I stumbled upon Interbench.

This benchmark application is designed to benchmark interactivity in Linux. See the included file readme.interactivity for a brief definition.

It is designed to measure the effect of changes in Linux kernel design or system configuration changes such as cpu, I/O scheduler and filesystem changes and options. With careful benchmarking, different hardware can be compared.

Another tool that could come in handy is from Con Kolivas again and is called ConTest.

This program is designed to test system responsiveness by running kernel compilation under a number of different load conditions. It is designed to compare different kernels, not different machines. It uses real workloads you'd expect to find for short periods in every day machines but sustains them for the duration of a kernel compile to increase the signal to noise ratio.

so maybe you could use this by preparing two kernel with different schedulers.