[lkml]   [2003]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectKernel 2.6.0-test2 vs 2.2.12 -- Some observations
    	So now that 2.6.0-test2 runs on a 386EX/25 with 8MB of memory, and the CF 
    disk is working properly, I have a few observations regarding the change in
    kernels, and the impact that I see.

    These are not (necessarily) judgements, and the comparison may not be 100% on
    equal footing, but nonetheless, they're what I see. If you have suggestions,
    I'll be happy to try them. So, with abestos suite in standby mode:

    Both kernels are very limited in what's compiled in. Basically, it's 386
    optioned, with math emulation enabled, IDE for hard disk only, PPP with
    compression, ethernet (but no drivers, just enough so that PPP works),
    SYSVIPC, ext2 support, /proc support, serial console (serial.h has been
    modified for 6 serial ports, 2 16450s (the 386EX native ports), and 2
    external 16C752's (each channel on a dedicated interrupt).

    The 2.2.12 version is compiled with GCC 2.91.66, the 2.6.0-test2 version with
    GCC 2.96.

    Kernel 2.2.12 is a BlueCat variation, which has some minor tweaks to reduce
    the footprint, modifications to remove real-time clock support, and the
    CLOCK_TICK_RATE changed from 1193180 to 1000000. The 2.6.0-test2 kernel has
    similiar modifications, implemented as much as possible in the mach-
    directories. 2.2.12 also has support for an AT1700 ethernet controller
    (whose hardware is not present in the system, currently). 2.6.0-test2 is
    build without this.

    2.2.12 compiles out at 755712 bytes, which is uncompressed (we don't compress
    the kernel because a 386EX/25 takes too long to uncompress). The values
    reported by the kernel as it comes up are: 6884k/8192k availale (596k kernel
    code, 416k reserved, 272k data, 24k init).

    2.6.0-tests compiles out at 1163392 bytes (again, uncompressed, for the same
    reason). The values reported by the kernel are: 6296k/8132k available (932k
    kernel code, 1424k reserved, 239k data, 68k init, 0k highmem). The
    CONFIG_EMBEDDED is set (admittedly, I haven't grepped the code to see what
    all this variable impacts).

    I'm sure the reserved value is something I'm failing to tune myself that's
    been tweaked into the BlueCat distro. That's something I need to look into.
    But 300K of code growth (33%!) for the same basic functionality strikes me
    as... not good. Any thoughts on this issue?

    For reasons unknown, whereas 2.2.12 picked up the values for how much memory
    we have stuffed into a fake BIOS block, 2.6.0-test2 does not (nor did
    2.5.69). I have to set a mem=7744k into the boot params. Anything more, and
    I get kernel paging faults at startup. I'm unclear why this is, but since it
    can be worked around at the moment, I can let it lay.

    2.2.12 reports 3.49 Bogomips, 2.6.0-test2 reports varying values, depending
    on what HZ is set to (more on this shortly). 4.14 for HZ=100, 8.19 for
    HZ=1000. I realize that Bogomips are meaningless, and didn't at some point
    the method for determining them change? I do find it odd that that the
    rating should change by changing the HZ value, however.

    Interactive performance is an atrocity with 2.6.0-test2. Something as simple
    as backspacing though a command line can cause overrun errors. Whereas
    before zmodeming a file down was not an issue with 2.2.12 (this, in fact, is
    how software is applied to the CF card), it fails completely under
    2.6.0-test2. In addition, I started getting 'serial8250: too much work for
    irq4'. Granted, the console port is a 16450, which has no FIFO. But to go
    to a newer kernel and get this error doesn't seem right. Perhaps there's
    some performance tuning I'm missing, but I do know that it was not required
    under 2.2.12, so I'm not sure why I would need to do that under 2.6.0-test2.

    I have not run hdparm on the drives, but e2fsck coming up on a dirty
    partition is amazingly slow on 2.6.0-test2. On a 32MB CF card with 25% usage
    (about 300 files), it takes less than 10 seconds under 2.2.12. On
    2.6.0-test2, I'm seeing on the order of 40+ seconds. Long enough, in fact,
    that the watchdog that makes sure the system has booted into the application
    is timing out and punting the system.

    Any thoughts or things to look for would be greatly appreciated. I realize
    that many people doing embedded work on small processors are using the older
    kernels. I'd like to use a newer one, since the device driver interface is
    so much cleaner, and I'd like to use a CF+WiFi card, which is not supported
    in the older kernels.

    I've posted the .config files, along with the and kernel images to The final images are run through "objcopy -O
    binary -R .note -R .comment -R .stab -R .stabstr vmlinux vmlinuz" to produce
    the image that goes into the FLASH parts.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:47    [W:0.025 / U:15.976 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site