code of process scheduling

[Nifty Hat Mitch]

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
> algorithms.as, far as i know they implement round-robn algorithms.for
> changing in linux kernel code  i want to know exactly where the kernel
> code relating process sceduling resides.(i.e. what is the path of the
> file containing the code related to the process scheduling and how
> much they are interrelated to other file.)
>   waiting for reply! 


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.

If you tinker with code as important as the scheduler I suspect that
the most important thing to do is to have a set of metrics to evaluate
the changes.

The current scheduler is complex and has a modest number of knobs in
the source for tuning.  These knobs may be more interesting than
algorithm changes.  Clearly (to me) you must optimize these knobs for
your test harness setup prior to switching algorithms.

Have you looked at the process structure to see if the various
counters and flags are in place to let you understand the impact of
your changes.

I hope you are not being confused by some ifdefs for experimental code
that is known to be unstable for many users.  Is your test frame single
or multi-processor....

The general test framework must include awareness of your set of
device drivers.  In my mind a scheduler is a resource scheduler.
Time+CPU cycles are only two of a long list of resources.  Scheduler
knobs should permit optimization for hardware (IMO).  i.e. cost 
analysis... needs to know costs.

Of interest scheduling algorithms are like sorting algorithms. 
Much depends on the data/ load.

Profiling....?

What level of school is this for.
Good luck, 


-- 
	T o m  M i t c h e l l 
	Me, I would "Rather" Not.