I have a project on Linux CPU Scheduler to make it Fair Share
Scheduler.I will make some changes on some files such as sched.c vs...I will
want to see the effect ot the change but recompilation of the kernel takes
about half an hour on my machine.How can I minimize this time?Which part
should I necessarily include in my config file for the kernel to minimize
it?
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
On Thursday, 25 October 2001, at 18:20:25 +0300,
Omer Sever wrote:
> I have a project on Linux CPU Scheduler to make it Fair Share
> Scheduler.I will make some changes on some files such as sched.c vs...I will
> want to see the effect ot the change but recompilation of the kernel takes
> about half an hour on my machine.How can I minimize this time?Which part
> should I necessarily include in my config file for the kernel to minimize
> it?
>
make is your friend: it will only recompile those files that changed from
the last compilation. If you modify some #includes in the code, I believe
you will have to also run "make dep" before, to get dependencies right.
Another approach would be to compile the kernel on another different
machine, should you have one more powerful that the one you expect to try
the kernel on.
--
Jos? Luis Domingo L?pez
Linux Registered User #189436 Debian Linux Woody (P166 64 MB RAM)
jdomingo EN internautas PUNTO org => ? Spam ? Atente a las consecuencias
jdomingo AT internautas DOT org => Spam at your own risk
On Thu, 2001-10-25 at 16:37, Jos? Luis Domingo L?pez wrote:
> On Thursday, 25 October 2001, at 18:20:25 +0300,
> Omer Sever wrote:
>
> > I have a project on Linux CPU Scheduler to make it Fair Share
> > Scheduler.I will make some changes on some files such as sched.c vs...I will
> > want to see the effect ot the change but recompilation of the kernel takes
> > about half an hour on my machine.How can I minimize this time?Which part
> > should I necessarily include in my config file for the kernel to minimize
> > it?
> >
> make is your friend: it will only recompile those files that changed from
> the last compilation. If you modify some #includes in the code, I believe
> you will have to also run "make dep" before, to get dependencies right.
Except, as I discovered recently in playing around with the scheduler,
if you modify sched.h, you basically have to recompile the entire
kernel, as it seems everything depends on it.
On that note, why is add_to_runqueue() in sched.c and
del_from_runqueue() in sched.h? del_from_runqueue being the only func I
was modifying in sched.h (really annoying have to recompile an entire
kernel multiple times in a vmware vm, albiet thats not a good reason to
move it, I'm just wondering why they are split in 2 different files)
thanks,
shaya
On 25 Oct 2001, Shaya Potter wrote:
> On Thu, 2001-10-25 at 16:37, Jos? Luis Domingo L?pez wrote:
> > On Thursday, 25 October 2001, at 18:20:25 +0300,
> > Omer Sever wrote:
[SNIPPED...]
>
> On that note, why is add_to_runqueue() in sched.c and
> del_from_runqueue() in sched.h?
add_to_runqueue() is a function in sched.c
del_from_runqueue() is an macro. Macros generally go into header files.
These kinda need to be associated with sched.c because of:
static LIST_HEAD(runqueue_head);
plus some spinlocks.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
On 20011025 Omer Sever wrote:
> I have a project on Linux CPU Scheduler to make it Fair Share
>Scheduler.I will make some changes on some files such as sched.c vs...I will
>want to see the effect ot the change but recompilation of the kernel takes
>about half an hour on my machine.How can I minimize this time?Which part
>should I necessarily include in my config file for the kernel to minimize
>it?
>
Try this (and please tell me if it is worthy or I have to send it to trash)
--- linux-2.4.1-ac14/Makefile.org Thu Feb 15 15:47:42 2001
+++ linux-2.4.1-ac14/Makefile Thu Feb 15 15:48:11 2001
@@ -241,6 +241,9 @@
include arch/$(ARCH)/Makefile
+
+CC:=$(CC)
+CPP:=$(CPP)
export CPPFLAGS CFLAGS AFLAGS
--
J.A. Magallon # Let the source be with you...
mailto:[email protected]
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.14-pre1-beo #1 SMP Thu Oct 25 16:19:19 CEST 2001 i686
Shaya Potter wrote:
>
> On Thu, 2001-10-25 at 16:37, Jos? Luis Domingo L?pez wrote:
> > On Thursday, 25 October 2001, at 18:20:25 +0300,
> > Omer Sever wrote:
> >
> > > I have a project on Linux CPU Scheduler to make it Fair Share
> > > Scheduler.I will make some changes on some files such as sched.c vs...I will
> > > want to see the effect ot the change but recompilation of the kernel takes
> > > about half an hour on my machine.How can I minimize this time?Which part
> > > should I necessarily include in my config file for the kernel to minimize
> > > it?
> > >
> > make is your friend: it will only recompile those files that changed from
> > the last compilation. If you modify some #includes in the code, I believe
> > you will have to also run "make dep" before, to get dependencies right.
>
> Except, as I discovered recently in playing around with the scheduler,
> if you modify sched.h, you basically have to recompile the entire
> kernel, as it seems everything depends on it.
>
> On that note, why is add_to_runqueue() in sched.c and
> del_from_runqueue() in sched.h? del_from_runqueue being the only func I
> was modifying in sched.h (really annoying have to recompile an entire
> kernel multiple times in a vmware vm, albiet thats not a good reason to
> move it, I'm just wondering why they are split in 2 different files)
>
Somewhere back around 2.2.15 (or so) a change was made that has the smp
cpu start up code removing the start up task from the run list. I think
you will find the del_from_runqueue() is only used in this case. It
could have been done in init_idle() in sched.c (in fact the code is
there) but it is also done prior to this call. Sigh...
George