Intel TX chipset: 64MB RAM cached, best use for RAM >64MB?

[hpstr]

Hi,

after playing a bit around with TinyCore on my main rig, I`d like to use it on my good old Fujitsu Lifebook Biblo B110, Intel P1-233 and 96 MB RAM.

However, the Biblo, as many computers of this era, uses the Intel TX chipset, known for a limitation of the L2 cache: only 64MB RAM are cached.
I`m not sure how this problem may affect distributions like TinyCore that run entirely from RAM. TinyCore`s kernel, according to the docs, doesn`t seem to consider a mem parameter.

On classic Linux installations, it was once a common workaround to limit the kernel to 64 MB RAM with boot parameter mem=64M, and to use the rest of the RAM as a swap partition in memory.

Any suggestions or experiences?

Thx, regards,

Hans

[tinypoodle]

TinyCore`s kernel, according to the docs, doesn`t seem to consider a mem parameter.

According to which docs exactly?
I searched and couldn't find any relevant kernel config option.

[curaga]

AFAIK we take the mem param just fine.

[hpstr]

AFAIK we take the mem param just fine.

In my initial post, I was referring to the documented TC boot parameters. Indeed the TC kernel accepts the mem parameter.

I tried it out, and could not see any significant change in performance yet.

However I don`t have any applications installed, as I don`t have a wired PCMCIA NIC and could not get wireless networking right yet. Downloading and installing apps by hand, copying them via USB memory from another networked PC, is a bit of a pain, especially the dependencies.

However, after fiddling a bit with the framebuffer (Xvesa causes interesting green tinted graphics on the B110), TC runs basically fine without the mem=64MB parameter.

Maybe when I`m able to the install the desired applications by network, I`ll try both configurations to see if they affect performance.

[^thehatsrule^]

See the last line of http://tinycorelinux.com/faq.html#bootcodes

[hpstr]

See the last line of http://tinycorelinux.com/faq.html#bootcodes

Thanks. I`ve seen it, but only after my last post; it`s easy to miss it because of the different font after the block characters.

After some days of playing with the mem parameter, I noticed no obvious performance issues with or without.
I installed most packages on demand only, to keep boot time as short as possible, and the heaviest package installed is the Opera browser, having no further dependencies. So YMMV using more applications with additional dependencies.

The B110 is a joy to use with TC.

Following is OT, better in a separate thread?

One fact that I appreciate much is not emphasized on the main page and in the FAQ - it is the ease of updating the core distribution. As 3.3 and 3.4 share the same kernel, the only file to update for me was tinycore.gz.

The separation of kernel + base distribution from the package repository seems somewhat BSD-like to me, and the lack of that, causing the need to perform a complete update between versions, is a drawback for many major Linux distributions.
Maybe you should mention this fact in a more prominent place, as it is a big advantage?

Another further suggestion would be to change the default name of the kernel binary from bzImage to tinycore3.4 and the ramdisk image tinycore3.4.gz or similar. This could be useful, as in many environments TC might coexist with other kernels and images in the /boot/ directory, and would make it easy to do scripted automatic core updates.
IIRC a long time ago it was necessary to name the kernel binary according to it`s compression (bzImage, vmlinuz, ecc. - was it for LILO?), but that is not necessary anymore.

And, having to use Xfbdev, I found even some unexpected bloat... the fb logo

Thanks for the great distribution. Maybe sooner or later I can contribute some packages.

Regards,

Hans

[tinypoodle]

Another further suggestion would be to change the default name of the kernel binary from bzImage to tinycore3.4 and the ramdisk image tinycore3.4.gz or similar. This could be useful, as in many environments TC might coexist with other kernels and images in the /boot/ directory, and would make it easy to do scripted automatic core updates.

That would break compatibility with DOS based Linux loaders.

[gerald_clark]

I don't see how "/boot/tc/bzImage" would be any more difficult than "/boot/bzImage" in a script.
I have several versions on my test machine.
/boot/tc-3.2/
/boot/tc-3.3/
/boot/tc-3.4/

[curaga]

FWIW, even if you rename it locally, wget can handle that fine.

wget -O tinycore3.4 http://..../bzImage

[hpstr]

Thanks for the suggestions. In fact I do use wget this way for my updates.

I see that is not as easy as I thought; I didn`t remember loadlin... Well, I`ll have my planned update script check the md5s instead.

[tinypoodle]

Actually I use linld, which is written by the maintainer of busybox, so to speak - my bootloader comes assorted with the core of the Core  ;-)

Your loadlin reference is somehow funny to me though, as coincidentally yesterday I happened to have an encounter with someone mentioning to use loadlin as bootloader.
When I replied that I had been using loadlin for many years until it simply didn't work with newer kernels any more, the user in surprise exclaimed that loadlin had always worked well for him.
Turned out that he only first time used loadlin after it had been given a total overhaul by it's new maintainer...