sir! i did n't get any response from you and other developers.please sendme the informations that you have. Abhijit On Thu, 14 Oct 2004 17:49:44 +0530, abhijit kumar <kumarabhijit@xxxxxxxxx> wrote: > sir! > i am working on FC2 because this is the version available in my > institute.when i 've tried to study the sched.c > (/usr/src/linux-2.6.5-1.358/kernel/sched.c) , i came to know that same > MACRO name is used in so many different files. so , it was very hard > to understand that which file sched.c is using. I 've tried the gcc - > E for getting the preprocessed file so that i may be able to locate > the files the sched is using. i 've found that by > compling/preprocessing thius file through gcc sched.c is n't able to > include mm.h,nmi.h etc. files.actually sched.c try to include the > files from /usr/include/linux directory not from > /usr/src/linux-2.6.5-1.358/include/linux where the files mm.h, nmi.h > etc. are available. i don't know which directory is actually used for > Kernel compilation . so; please give me some idea. > one more thing i 've n't used "make" utility to compile kernel. > i've used developer option during installation of FC2 . is it enough ? > as; i 'm gettingcompiled code in /usr/src/linux-2.6.5-1.358 directory. > > > Abhijit > > > > > On Thu, 7 Oct 2004 01:13:22 -0700, Nifty Hat Mitch > <mitch48@xxxxxxxxxxxxx> wrote: > > On Tue, Oct 05, 2004 at 12:51:12PM -0700, Nifty Hat Mitch wrote: > > > On Sat, Oct 02, 2004 at 08:11:28AM +0530, abhijit kumar wrote: > > > > > > > > dear programmers! > > > > i am student pursuing a project on CORE fedora2. i want to change > > > > the sceduling algorithms used by the linux kernel and apply other > > .... > > > > > I see that others have given you pointers to some files. > > > I suggest that you work on the current FC3 test version (FC3T2). > > > Developers will be more helpfull if you are forward looking. > > ... > > > What I am curious about are the goals of the project. > > > > Since abhijit and I swapped some off line mail on this school > > project I suspect I should share my thoughts as they are of > > general interest. > > > > At one level this is a benchmarking project. > > Benchmarking may be the single most important part! > > > > First use Google search and collect some standard benchmark tools. I > > would start with "lmbench". These small benchmark tools are > > instrumented (have clock/ timer functions built in already. Next > > build some benchmarks of your own design. Hint, use exercises from > > previous classes. > > > > Next in sched.c (/usr/src/linux-2.6.8-1.521/kernel/sched.c) play with > > the existing scheduler and see what changes. This does require that > > you recompile the kernel but does not require more or new code. You > > can still break the system but the scope of change is more bounded. > > > > Look for this code in kernel source. > > /* > > * These are the 'tuning knobs' of the scheduler: > > * > > * Minimum timeslice is 10 msecs, default timeslice is 100 msecs, > > * maximum timeslice is 200 msecs. Timeslices get refilled after > > * they expire. > > */ > > #define MIN_TIMESLICE ( 10 * HZ / 1000) > > #define MAX_TIMESLICE (200 * HZ / 1000) > > #define ON_RUNQUEUE_WEIGHT 30 > > #define CHILD_PENALTY 95 > > #define PARENT_PENALTY 100 > > #define EXIT_WEIGHT 3 > > #define PRIO_BONUS_RATIO 25 > > #define MAX_BONUS (MAX_USER_PRIO * PRIO_BONUS_RATIO / 100) > > #define INTERACTIVE_DELTA 2 > > #define MAX_SLEEP_AVG (AVG_TIMESLICE * MAX_BONUS) > > #define STARVATION_LIMIT (MAX_SLEEP_AVG) > > > > The point in this step is the point is that a scheduler must balance > > various activities. These kernel knobs control this balance as much > > or more than the algorithm. > > > > There are also user space knobs.... > > > > As you work through the above you can look at scheduler code > > and make other specific changes based on what you discover > > in your baseline benchmarking and analysis. > > > > Once the current scheduler has been parametrized you may understand > > which benchmarks are scheduler sensitive and why. > > > > Some of the benchmark code you write should be selectively greedy for > > various system resources. > > > > One obvious thing to watch for and measure is application startup > > time. Here is the classic hello world (a.out). Note that most timing > > tools are handy and require no special code. Of interest the > > variability of run times is a result of scheduler actions. > > > > $ time a.out > > Hello world > > > > real 0m0.004s > > user 0m0.001s > > sys 0m0.002s > > $ time a.out > > Hello world > > > > real 0m0.005s > > user 0m0.000s > > sys 0m0.003s > > > > And simple "needs a window stuff" like this are fun... > > > > $ time xterm -e a.out > > > > real 0m0.305s > > user 0m0.085s > > sys 0m0.026s > > > > Also for handy but non trivial benchmark stuff look at stuff like > > glxgears and x11perf. There are also httpd and CGI benchmarks.... > > > > Do not ignore application profiling (strace, ltrace) and kernel profiling > > as benchmark tools. > > > > Quiz for scheduler "want to be authors": > > > > Given: > > A two man racing team. > > Race is 100 Km in length. > > The first team member drives the first half at 50Km/hr. > > > > Question 1: > > How fast must the second driver drive the second > > half of the race for the TEAM to average 100Km/hour? > > > > Question 2: > > Essay, How the heck does this apply to the Linux scheduler. > > > > > > > > > > -- > > T o m M i t c h e l l > > Me, I would "Rather" Not. > > >
