m68k 2.6.26-1 vs 2.4.30 comparison

m68k 2.6.26-1 vs 2.4.30 comparison

[Lance Tagliapietra]

Hello,

I've (finally) been moving my Amiga 2000/030/16M system to a 2.6 series kernel.
I have started with the 2.6.26 that I downlaoded from [1] because it had support for NFS.
I have also used git to pull the sources for m68k 2.6.29 and am working on compiling the 
smallest footprint kernel for my hardware.

Observations:
a). I 2.4.30 kernel compile was about 6 hours on this hardware (GCC 2.95.4).  The 2.6.29
took 4 days (GCC 4.1.2, Debian).  That was without the modules, too.  Now, it did select
the config option for smallest code size, and perhaps that is not well supported for m68k
and also added to the compile time. Make was done as nice -n 17 but the system is mostly 
idle, otherwise, but that is how I compile the 2.4.30.

b). My custom 2.4.30 kernel size is about 750K uncompressed. With setting the options to
remove support for hardware that I don't have and features that I don't need, I still 
came up with a kernel of 2.7M.  The goal is to have the smallest footprint kernel possible.

c). The 2.6.26 kernel seems to want to keep more memory free and hit the swap much more
than the 2.4.30 kernel according to vmstat.  Under 2.4.30 I see the free memory go as low
as about 200K, and it will remain at that level as long as is necessary.  Under 2.6.26,
the free memory stays at about 800K, and if it drops below that, it will come back to that
level relatively quickly.

d). The real time clock came up on the worng month, going from 2.4.30 to 2.6.26 (or 28),
March vs April, in this case.

Questions:

e). Is there an option which tells the kernel the minimum amount of free RAM to maintain 
as I describe in (c) above?  RAM is relatively precious in my m68k environment, and having
500k being held in reserve seems a bit much?

f). The kernel config gives options for 3 schedulers. Does anyone here know which gives the 
smallest memory footprint?

Thanks,

--Lance

[1] http://people.debian.org/~smarenka/

Re: m68k 2.6.26-1 vs 2.4.30 comparison

[Geert Uytterhoeven]

On Sun, May 3, 2009 at 09:28, Lance Tagliapietra <lancetag@luminet.net> wrote:
> b). My custom 2.4.30 kernel size is about 750K uncompressed. With setting the options to
> remove support for hardware that I don't have and features that I don't need, I still
> came up with a kernel of 2.7M.  The goal is to have the smallest footprint kernel possible.

Yeah, minimum kernel size has increased :-(

> c). The 2.6.26 kernel seems to want to keep more memory free and hit the swap much more
> than the 2.4.30 kernel according to vmstat.  Under 2.4.30 I see the free memory go as low
> as about 200K, and it will remain at that level as long as is necessary.  Under 2.6.26,
> the free memory stays at about 800K, and if it drops below that, it will come back to that
> level relatively quickly.

As memory consumption is general. I didn't do exact measurements, but
2.6 consumes ca. 1.5 MiB
more on my A4000 (with 12 MiB of fast RAM). Booting and running Debian
is slow, while I used to
have more daemons installed, in a time the machine was actually used
as a mailserver for 70 people,
some of which read their email by logging in and running pine...

> d). The real time clock came up on the worng month, going from 2.4.30 to 2.6.26 (or 28),
> March vs April, in this case.

That's an interesting one...

In 2.4.30, you have both a2000_gettod() (for boot time setting), which does:

    *monp  = tod_2000.month1      * 10 + tod_2000.month2;

and amiga_hwclk() (for /dev/rtc), which does:

    t->tm_mon  = tod_2000.month1      * 10 + tod_2000.month2 - 1;

In 2.6.29, you only have a2000_hwclk(), which does

    t->tm_mon  = tod_2000.month1      * 10 + tod_2000.month2 - 1;

The data returned by a2000_gettod() is converted to seconds using mktime(),
which assumes months are in the range 1..12.

amiga_hwclk() and a2000_hwclk() both use struct rtc_time. This should
be similar to
struct tm in <time.h>, where the months are in the range 0..11.
Both rtc_proc_output()/gen_rtc_proc_output() (2.4.30) and
rtc_proc_show() (2.6.29) do
print tm.tm_mon + 1 to make them be in the range 1..12.

So at first sight, I don't see where the bug is...

What does `hwlock -ur` say, on both 2.4.30 and 2.6.29?

> Questions:
>
> e). Is there an option which tells the kernel the minimum amount of free RAM to maintain
> as I describe in (c) above?  RAM is relatively precious in my m68k environment, and having
> 500k being held in reserve seems a bit much?

Probably one of those swappiness parameters under /sys. Don't ask me
which one...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: m68k 2.6.26-1 vs 2.4.30 comparison

[Kolbjørn Barmen]

On Sun, 3 May 2009, Lance Tagliapietra wrote:

> Observations:
> a). I 2.4.30 kernel compile was about 6 hours on this hardware (GCC 2.95.4).  The 2.6.29
> took 4 days (GCC 4.1.2, Debian).  That was without the modules, too.  Now, it did select
> the config option for smallest code size, and perhaps that is not well supported for m68k
> and also added to the compile time. Make was done as nice -n 17 but the system is mostly
> idle, otherwise, but that is how I compile the 2.4.30.

Most of the times is spent "entering directory bla; : nothing to do here;
leaving directory bla" - 2.6 is much bigger in terms of number of
directories/files to parse through, and on slow IO that certainly matters :)

> b). My custom 2.4.30 kernel size is about 750K uncompressed. With setting the options to
> remove support for hardware that I don't have and features that I don't need, I still
> came up with a kernel of 2.7M.  The goal is to have the smallest footprint kernel possible.

My amiga kernel, which is not optimized for size, has ipv6 and lots of stuff,,
is 2170192 bytes, stripped. I suspect you have not stripped yours?

> c). The 2.6.26 kernel seems to want to keep more memory free and hit the swap much more
> than the 2.4.30 kernel according to vmstat.  Under 2.4.30 I see the free memory go as low
> as about 200K, and it will remain at that level as long as is necessary.  Under 2.6.26,
> the free memory stays at about 800K, and if it drops below that, it will come back to that
> level relatively quickly.

What does "sysctl vm.min_free_kbytes" say?
Here it says "vm.min_free_kbytes = 1763"

> d). The real time clock came up on the worng month, going from 2.4.30 to
> 2.6.26 (or 28), March vs April, in this case.

Hm, this sounds familiar, allthough I cant pinpoint it.

> e). Is there an option which tells the kernel the minimum amount of free RAM to maintain
> as I describe in (c) above?  RAM is relatively precious in my m68k environment, and having
> 500k being held in reserve seems a bit much?

I'd try with "sysctl -w vm.min_free_kbytes=500" and see if that helps.
If it does, make it permanent by adding it to /etc/sysctl.conf

> f). The kernel config gives options for 3 schedulers. Does anyone here know which gives the
> smallest memory footprint?

I'm clueless on this one.

-- kolla

Re: m68k 2.6.26-1 vs 2.4.30 comparison

[Lance Tagliapietra]

On Wed, May 06, 2009 at 08:44:41AM +0200, Kolbj??rn Barmen wrote:
> On Sun, 3 May 2009, Lance Tagliapietra wrote:
> 
> > Observations: a). I 2.4.30 kernel compile was about 6 hours on this hardware (GCC 2.95.4).  The 2.6.29 took 4 days 
> > (GCC 4.1.2, Debian).  That was without the modules, too.  Now, it did select the config option for smallest code 
> > size, and perhaps that is not well supported for m68k and also added to the compile time. Make was done as nice -n 
> > 17 but the system is mostly idle, otherwise, but that is how I compile the 2.4.30.
> 
> Most of the times is spent "entering directory bla; : nothing to do here; leaving directory bla" - 2.6 is much bigger 
> in terms of number of directories/files to parse through, and on slow IO that certainly matters :)

Also, what seemed to be different is that this compile called a shell script for each file being compiled.  I'm not sure 
if that was generated by the Makefile at build time yet.  My other thought is that GCC 4.1.x has a larger footprint than 
GCC 2.95 as it seemed to swap more than under the 2.4.30 / GCC 2.95.x.

> 
> > b). My custom 2.4.30 kernel size is about 750K uncompressed. With setting the options to remove support for hardware 
> > that I don't have and features that I don't need, I still came up with a kernel of 2.7M.  The goal is to have the 
> > smallest footprint kernel possible.
> 
> My amiga kernel, which is not optimized for size, has ipv6 and lots of stuff,, is 2170192 bytes, stripped. I suspect 
> you have not stripped yours?

Point of clarification: I was changing the .config to remove support for hardware (don't even make as a module) and 
features that I don't need in the kernel.  Was there another method being referred to with the term 'stripped' above?

> 
> > c). The 2.6.26 kernel seems to want to keep more memory free and hit the swap much more than the 2.4.30 kernel 
> > according to vmstat.  Under 2.4.30 I see the free memory go as low as about 200K, and it will remain at that level 
> > as long as is necessary.  Under 2.6.26, the free memory stays at about 800K, and if it drops below that, it will 
> > come back to that level relatively quickly.
> 
> What does "sysctl vm.min_free_kbytes" say? Here it says "vm.min_free_kbytes = 1763"

500
> 
> > d). The real time clock came up on the worng month, going from 2.4.30 to 2.6.26 (or 28), March vs April, in this 
> > case.
> 
> Hm, this sounds familiar, allthough I cant pinpoint it.

Geert responded to this in a previous mail to the group, I have to get some information back to him.

> 
> > e). Is there an option which tells the kernel the minimum amount of free RAM to maintain as I describe in (c) above?  
> > RAM is relatively precious in my m68k environment, and having 500k being held in reserve seems a bit much?
> 
> I'd try with "sysctl -w vm.min_free_kbytes=500" and see if that helps. If it does, make it permanent by adding it to 
> /etc/sysctl.conf

Thanks so much for this suggestion!!!  I set the value to 200, and I so far have not seen the value (via vmstat) go 
below 200, lowest observed so far has been 244.  This might be a good suggestion for m68k to make permanent?

--Lance

Re: m68k 2.6.26-1 vs 2.4.30 comparison

[Michael Schmitz]

Hi,

> > > b). My custom 2.4.30 kernel size is about 750K uncompressed. With setting the options to remove support for hardware 
> > > that I don't have and features that I don't need, I still came up with a kernel of 2.7M.  The goal is to have the 
> > > smallest footprint kernel possible.
> > 
> > My amiga kernel, which is not optimized for size, has ipv6 and lots of stuff,, is 2170192 bytes, stripped. I suspect 
> > you have not stripped yours?
> 
> Point of clarification: I was changing the .config to remove support for hardware (don't even make as a module) and 
> features that I don't need in the kernel.  Was there another method being referred to with the term 'stripped' above?

The 'strip' command (part of binutils) does remove symbol tables from the kernel 
image file. This does reduce the image file size. I am not sure that it does 
reduce the memory footprint. 

Part of the kernel code is now stored in sections of the image that are later 
freed if the corresponding code is no longer used. You should not expect a 
simple 1:1 correlation between kernel image file and memory footprint. 

	Michael

Re: m68k 2.6.26-1 vs 2.4.30 comparison

[Lance Tagliapietra]

On Sun, May 03, 2009 at 01:08:06PM +0200, Geert Uytterhoeven wrote:
> > d). The real time clock came up on the worng month, going from 2.4.30 to 2.6.26 (or 28),
> > March vs April, in this case.
> 
> That's an interesting one...
> 
> In 2.4.30, you have both a2000_gettod() (for boot time setting), which does:
> 
>     *monp  = tod_2000.month1      * 10 + tod_2000.month2;
> 
> and amiga_hwclk() (for /dev/rtc), which does:
> 
>     t->tm_mon  = tod_2000.month1      * 10 + tod_2000.month2 - 1;
> 
> In 2.6.29, you only have a2000_hwclk(), which does
> 
>     t->tm_mon  = tod_2000.month1      * 10 + tod_2000.month2 - 1;
> 
> The data returned by a2000_gettod() is converted to seconds using mktime(),
> which assumes months are in the range 1..12.
> 
> amiga_hwclk() and a2000_hwclk() both use struct rtc_time. This should
> be similar to
> struct tm in <time.h>, where the months are in the range 0..11.
> Both rtc_proc_output()/gen_rtc_proc_output() (2.4.30) and
> rtc_proc_show() (2.6.29) do
> print tm.tm_mon + 1 to make them be in the range 1..12.
> 
> So at first sight, I don't see where the bug is...
> 
> What does `hwlock -ur` say, on both 2.4.30 and 2.6.29?

I'm afraid the result isn't going to be helpful just yet (assuming you meant hwclock, not hwlock):

hwclock -ur
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.

hwclock --debug
hwclock: Open of /dev/rtc failed, errno=19: No such device.
Cannot access the Hardware Clock via any known method.
hwclock from util-linux-2.12r
No usable clock interface found.

Now, there is a /dev/rtc device of type 10 135.  Interestingly, though is that the 
kernel is looking for an "rtc0" device based on the kernel config.  So I'll make
that change to the kernel config and re-build and see what I get -- or would it 
be a better approach to add a /dev/rtc0 c 10 135?

Thanks,

--Lance

Re: m68k 2.6.26-1 vs 2.4.30 comparison

[Andreas Schwab]

Lance Tagliapietra <lancetag@Luminet.net> writes:

> Now, there is a /dev/rtc device of type 10 135.  Interestingly, though is that the 
> kernel is looking for an "rtc0" device based on the kernel config.  So I'll make
> that change to the kernel config and re-build and see what I get -- or would it 
> be a better approach to add a /dev/rtc0 c 10 135?

I think you need a c 254 0 device if you use rtc-generic.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k 2.6.26-1 vs 2.4.30 comparison

[Geert Uytterhoeven]

On Fri, May 15, 2009 at 11:31, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Lance Tagliapietra <lancetag@Luminet.net> writes:
>
>> Now, there is a /dev/rtc device of type 10 135.  Interestingly, though is that the
>> kernel is looking for an "rtc0" device based on the kernel config.  So I'll make
>> that change to the kernel config and re-build and see what I get -- or would it
>> be a better approach to add a /dev/rtc0 c 10 135?
>
> I think you need a c 254 0 device if you use rtc-generic.

Note that the actual number may change, as it's a dynamic major.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Amiga RTC kernel config [was: Re: m68k 2.6.26-1 vs 2.4.30 comparison]

[Lance Tagliapietra]

On Fri, May 15, 2009 at 11:31:12AM +0200, Andreas Schwab wrote:
> Lance Tagliapietra <lancetag@Luminet.net> writes:
> 
> > Now, there is a /dev/rtc device of type 10 135.  Interestingly, though is that the 
> > kernel is looking for an "rtc0" device based on the kernel config.  So I'll make
> > that change to the kernel config and re-build and see what I get -- or would it 
> > be a better approach to add a /dev/rtc0 c 10 135?
> 
> I think you need a c 254 0 device if you use rtc-generic.
> 
> Andreas.
> 
> -- 
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

I beleive I made a mistake here.  I compiled my kernel (and the other 2.6.xx
kernels I have tried) were compiled with CONFIG_RTC_CLASS=y instead of
CONFIG_GEN_RTC=Y and CONFIG_GEN_RTC_X=y which I have now determined are the 
defaults for the m68k arch, and also the options used in my properly working
2.4.30 kernel.

That is why the "/dev/rtc0" showed up in the .config.
I am re-building my kernel to test.

Thanks,

--Lance

Re: Amiga RTC kernel config [was: Re: m68k 2.6.26-1 vs 2.4.30 comparison]

[Lance Tagliapietra]

On Fri, May 15, 2009 at 12:02:13PM -0500, Lance Tagliapietra wrote:
> On Fri, May 15, 2009 at 11:31:12AM +0200, Andreas Schwab wrote:
> > Lance Tagliapietra <lancetag@Luminet.net> writes:
> > 
> > > Now, there is a /dev/rtc device of type 10 135.  Interestingly, though is that the 
> > > kernel is looking for an "rtc0" device based on the kernel config.  So I'll make
> > > that change to the kernel config and re-build and see what I get -- or would it 
> > > be a better approach to add a /dev/rtc0 c 10 135?
> > 
> > I think you need a c 254 0 device if you use rtc-generic.
> > 
> > Andreas.
> > 
> > -- 
> > Andreas Schwab, schwab@linux-m68k.org
> > GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> > "And now for something completely different."
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> I beleive I made a mistake here.  I compiled my kernel (and the other 2.6.xx
> kernels I have tried) were compiled with CONFIG_RTC_CLASS=y instead of
> CONFIG_GEN_RTC=Y and CONFIG_GEN_RTC_X=y which I have now determined are the 
> defaults for the m68k arch, and also the options used in my properly working
> 2.4.30 kernel.
> 
> That is why the "/dev/rtc0" showed up in the .config.
> I am re-building my kernel to test.
> 
> Thanks,
> 
> --Lance
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

After re-building the kernel 2.6.29.1 for the real time clock support:

CONFIG_GEN_RTC=y 
CONFIG_GEN_RTC_X=y

the read time clock is being properly read at boot.  I no longer see the 
month being off by 1 (i.e. April vs May reported) and hwclock -ur response
with the correct time as expected.

--Lance