Re: Fast testing

Re: Fast testing

[Tomasz Chmielewski]

> On 4/14/09, Dragoslav Zaric <dragoslav.zaric.kd@gmail.com> wrote:
>> Hello,
>>
>> I have question regarding fast testing of some change in some kernel
>> source file. Since rebooting is a long process,

Use kexec to "reboot" faster.


> there must be way to
>> test some change faster [of course only if source file is not some boot
>> connected file, but maybe this is also doable].

Compile the things you want to test as modules, if possible.


-- 
Tomasz Chmielewski
http://wpkg.org

Re: Fast testing

[devzero]

if your kernel changes are not driver/hardware specific and you want to test/develop more
generic features, then you should have a look at UserModeLinux. great for testing & debugging.
you donŽt need any bootloader to run UserModeLinux, you can start it from commandline 
just like any other process. Basically, it`s a Linux kernel ported to Linux API (instead of different ARCH)

regards
roland


List:       linux-kernel
Subject:    Re: Fast testing
From:       Dragoslav Zaric <dragoslav.zaric.kd () gmail ! com>
Date:       2009-04-14 16:44:43
Message-ID: 2d05c4580904140944s1dec7dfewf42862ac698bf669 () mail ! gmail ! com
[Download message RAW]

Well Arjan it looks that you have a nice laptop if that is your
reboot time :)

The idea about this is that when you have some idea and you
write code, doing reboot and stuff can make you forgot your idea.
If you write normal program you probably press "build" or type
"gcc" at least 10 times to see what is going on. I think that only
thing necessary is: system to boot one time and then you can
load image in ram memory as many times as you want. So I am
not sure if this is ok, but at least I will try.

But I am not saying that if this works, the changes are going to
crush or freeze system more often than produce any kind of result :)

For example, we can boot from GRUB command line, so this would
be something like falling back to GRUB command line [to that point]
and load [any] image in ram memory.

thanks,

Dragoslav Zaric

__________________________________________________________________________
Verschicken Sie SMS direkt vom Postfach aus - in alle deutschen und viele 
ausländische Netze zum gleichen Preis! 
https://produkte.web.de/webde_sms/sms

Re: Fast testing

[Dragoslav Zaric]

Well the idea wasn't about what is faster, rebooting or loading
kernel image in ram memory, it was about loading kernel image
in ram to see and debug things. And if you reboot there is
time delay and the point is why doing it, if you can just smash
another kernel image in ram memory and drive.

I mean, this does not make sense in production environment use,
it is for debugging.

Anyway, the simplest first try is to get somehow at grub command
line and load kernel image in ram and hope this works :)
If not, then write small program is the only solution.

The only concern is can you burn your laptop with assembly instructions ?? :)

thanks,

Dragoslav Zaric

[Programmer; M. Sc Astrophysics]

Re: Fast testing

[Tomasz Chmielewski]

> Wow. Nice machine. I wish I had one like that. And how long until
> the GUI is usable again and you can actually continue working?
> 
> For comparison: my 3.4 GHz Pentium D takes 30 secs for kernel start
> (ie. until it begins looking for the filesystems),

Including all BIOS routines?


>  2 mins until the graphical login screen appears, and
> 5 mins from logging in to the GUI being completely present.

I have an old 366 MHz / 192 MB machine which boots to GUI much faster.

Something's wrong with your setup (unless you start really lots of 
things or have some other, "uncommon" things).


-- 
Tomasz Chmielewski
http://wpkg.org

Re: Fast testing

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]

Tomasz Chmielewski schrieb:
>> Wow. Nice machine. I wish I had one like that. And how long until
>> the GUI is usable again and you can actually continue working?
>> 
>> For comparison: my 3.4 GHz Pentium D takes 30 secs for kernel start
>> (ie. until it begins looking for the filesystems),
> 
> Including all BIOS routines?

No - from hitting Enter in the GRUB menu.

>>  2 mins until the graphical login screen appears, and
>> 5 mins from logging in to the GUI being completely present.
> 
> I have an old 366 MHz / 192 MB machine which boots to GUI much faster.

Might depend on the value of "GUI". Mine wouldn't even load in 192 MB.
Anyway, my preceding P3/700 MHz/512 MB box hasn't been much worse,
either.

> Something's wrong with your setup (unless you start really lots of 
> things or have some other, "uncommon" things).

Hmm, it's always been like that. As for "uncommon", this is a more
or less out of the box openSUSE 10.3 installation. (Without Beagle,
in case you were wondering.) Perhaps that's what's wrong? :-)

OTOH, even the GUIless CentOS server boxes I look after for a
living take about 5 mins until they are up and running again after
a kernel update - including BIOS, but without the fsck penalty.

Thanks,
Tilman

-- 
Tilman Schmidt                    E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: Fast testing

[Robert Hancock]

Tilman Schmidt wrote:
> Tomasz Chmielewski schrieb:
>>> Wow. Nice machine. I wish I had one like that. And how long until
>>> the GUI is usable again and you can actually continue working?
>>>
>>> For comparison: my 3.4 GHz Pentium D takes 30 secs for kernel start
>>> (ie. until it begins looking for the filesystems),
>> Including all BIOS routines?
> 
> No - from hitting Enter in the GRUB menu.

That seems really high, unless you're using some storage driver that 
takes a really long time to initialize or something..

> 
>>>  2 mins until the graphical login screen appears, and
>>> 5 mins from logging in to the GUI being completely present.
>> I have an old 366 MHz / 192 MB machine which boots to GUI much faster.
> 
> Might depend on the value of "GUI". Mine wouldn't even load in 192 MB.
> Anyway, my preceding P3/700 MHz/512 MB box hasn't been much worse,
> either.
> 
>> Something's wrong with your setup (unless you start really lots of 
>> things or have some other, "uncommon" things).
> 
> Hmm, it's always been like that. As for "uncommon", this is a more
> or less out of the box openSUSE 10.3 installation. (Without Beagle,
> in case you were wondering.) Perhaps that's what's wrong? :-)
> 
> OTOH, even the GUIless CentOS server boxes I look after for a
> living take about 5 mins until they are up and running again after
> a kernel update - including BIOS, but without the fsck penalty.
> 
> Thanks,
> Tilman
> 

Re: Fast testing

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]

On Wed, 15 Apr 2009 14:45:13 +0200, Tilman Schmidt said:
> > Something's wrong with your setup (unless you start really lots of=
> > things or have some other, "uncommon" things).
> 
> Hmm, it's always been like that. As for "uncommon", this is a more
> or less out of the box openSUSE 10.3 installation. (Without Beagle,
> in case you were wondering.) Perhaps that's what's wrong? :-)

Umm... shot in the dark - memory incorrectly flagged as non-cachable
by an mtrr?

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Fast testing

[Dragoslav Zaric]

Hello,

I have question regarding fast testing of some change in some kernel
source file. Since rebooting is a long process, there must be way to
test some change faster [of course only if source file is not some boot
connected file, but maybe this is also doable].

This is question:

When system is running, file that drives the system is "vmlinux" executable
and it is located in "/" or "/boot" folder. Let's say you change some kernel
source file and run "make" [this is fast since "make" should see that just few
files are changed]. After "make install" you should now have new "vmlinux" file.
Since state of cpu registers and memory locations determine current
system state, the change in binary system driver ["vmlinux"] should not
freeze system ? So if I copy new vmlinux over old vmlinux file can I see
change immediately ? I think it should continue to drive system without
problem because vmlinux is binary algorithm file, it does not contain any
data regarding current system state ? Also this assumes that your change does
not affect some large things, like memory segmentation tables and paging,
let's say it is more algorithmic and not structure change, because it is obvious
if you have structural change, current memory and register states
probably won't map
into new structure without system freeze.

Thanks,

Dragoslav Zaric,

[Programmer, M.Sc Astrophysics]

Re: Fast testing

[Alan Jenkins]

On 4/14/09, Dragoslav Zaric <dragoslav.zaric.kd@gmail.com> wrote:
> Hello,
>
> I have question regarding fast testing of some change in some kernel
> source file. Since rebooting is a long process, there must be way to
> test some change faster [of course only if source file is not some boot
> connected file, but maybe this is also doable].
>
> This is question:
>
> When system is running, file that drives the system is "vmlinux" executable
> and it is located in "/" or "/boot" folder.

Nope.

Kernel code (and data) is not demand-paged.  The kernel image is fully
loaded into memory at boot-time.  Changing /boot/vmlinuz will have no
effect on the running kernel.  And there are several other reasons why
what you describe would not work.

What you can do is compile some code as a module, and remove and
re-insert it to apply changes.  This doesn't work for core code or
your main disk driver though :-).

Alan

Re: Fast testing

[Dragoslav Zaric]

Hmm,

Ok, I found this on internet:
"The bzImage file is in a specific format: It contains concatenated
bootsect.o + setup.o + misc.o + piggy.o.
  piggy.o contains the gzipped vmlinux file in its data section (ELF)
(see compressed/Makefile piggy.o)."

So after we make new bzImage and "somehow" extract these four .o files
than we can manually load
kernel image into memory ? We can just run same routines that are run
during the boot, but we can skip
everything till piggy.o file, because the vmlinux file is in piggy.o ?

thanks,

Dragoslav Zaric

[Programmer, M.Sc Astrophysics]

Re: Fast testing

[Dragoslav Zaric]

The idea to compile targeted code like module is great,
so when changed, re-insert resolves problem fast and you
can see result immediately :)

thanks

Re: Fast testing

[Cyrill Gorcunov]

[Dragoslav Zaric - Tue, Apr 14, 2009 at 04:24:36PM +0200]
|
| The idea to compile targeted code like module is great,
| so when changed, re-insert resolves problem fast and you
| can see result immediately :)
| 
| thanks
| 

But don't be surprised if system gets down :)
Dragoslav (since I've been CC'ed on thread)
I believe the thread contains the mostly all testing
techniques I can imagine. qemu + thin distro image
is my preferred. And a real laptop as well.

        Cyrill

Re: Fast testing

[Andi Kleen]

Dragoslav Zaric <dragoslav.zaric.kd@gmail.com> writes:

As others pointed out vmlinux is not demand paged.

> Since rebooting is a long process,

The trick is to not make it a long process. Some ways to do that:

- Test simple changes in emulation. Emulators tend to boot faster
than real systems.
- Use a stripped down Linux distribution that boots fast. I found
that just using a old Linux distribution (without udev with static /dev) 
and minimal services boots dramatically faster. I use opensuse 10.0 for that.
- When you need to test on a real system use nfsroot with kernel
boot through PXE. First that saves you one iteration of rebooting/copying
to update a kernel. And then the NFS server can keep the small nfsroot cached
in memory and then deliver it immediately.

-Andi


-- 
ak@linux.intel.com -- Speaking for myself only.

Re: Fast testing

[Arjan van de Ven]

On Tue, 14 Apr 2009 11:55:10 +0200
Dragoslav Zaric <dragoslav.zaric.kd@gmail.com> wrote:

> Hello,
> 
> I have question regarding fast testing of some change in some kernel
> source file. Since rebooting is a long process, there must be way to

Rebooting is bloody fast for me (0.7 seconds for the kernel start,
about 3 to 4 seconds for the whole boot)....

not sure that doing weird magic to save that is worth it...


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: Fast testing

[Dragoslav Zaric]

Well Arjan it looks that you have a nice laptop if that is your
reboot time :)

The idea about this is that when you have some idea and you
write code, doing reboot and stuff can make you forgot your idea.
If you write normal program you probably press "build" or type
"gcc" at least 10 times to see what is going on. I think that only
thing necessary is: system to boot one time and then you can
load image in ram memory as many times as you want. So I am
not sure if this is ok, but at least I will try.

But I am not saying that if this works, the changes are going to
crush or freeze system more often than produce any kind of result :)

For example, we can boot from GRUB command line, so this would
be something like falling back to GRUB command line [to that point]
and load [any] image in ram memory.

thanks,

Dragoslav Zaric

[Programmer, M.Sc Astrophysics]

Re: Fast testing

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]

Arjan van de Ven schrieb:
> On Tue, 14 Apr 2009 11:55:10 +0200
> Dragoslav Zaric <dragoslav.zaric.kd@gmail.com> wrote:
> 
>> I have question regarding fast testing of some change in some kernel
>> source file. Since rebooting is a long process, there must be way to
> 
> Rebooting is bloody fast for me (0.7 seconds for the kernel start,
> about 3 to 4 seconds for the whole boot)....

Wow. Nice machine. I wish I had one like that. And how long until
the GUI is usable again and you can actually continue working?

For comparison: my 3.4 GHz Pentium D takes 30 secs for kernel start
(ie. until it begins looking for the filesystems), 6 mins for fsck
if it happens to decide my filesystems have gone too long without
checking, 2 mins until the graphical login screen appears, and
5 mins from logging in to the GUI being completely present.

> not sure that doing weird magic to save that is worth it...

Not for systems like yours, that's for sure, but perhaps for
systems like mine.

Thanks,
Tilman

-- 
Tilman Schmidt                    E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]