[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian/Linux on Atari TT



Hi,

On tiistai 22 tammikuu 2013, Thorsten Glaser wrote:
> Eero Tamminen dixit:
> >Issues where Hatari can help are unlikely to be dpkg related.
> 
> My idea was more to the point of testing the MMU, which
> would, I think, involve doing some sort of workload.

After looking more into this, the Hatari 030 MMU emulation isn't good
enough yet for this.  But 030 MMU emulation in WinUAE Amiga emulator
should now be:
	http://eab.abime.net/showthread.php?t=46934&page=4

And eventually it will get from there to Previous [1] and Hatari,
hopefully soon.   At that point Hatari should also be able to do
cache miss and more accurate instruction cycle profiling [2],
in case people want to speed up m68k Linux more.


[1] Previous is a NeXT emulator based on Hatari.
[2] This is being looked to help optimizing Doom for Falcon:
	http://www.atari-forum.com/viewtopic.php?f=26&t=6857&start=100
    currently it doesn't run at acceptable speed. :-)


> >All together the user-space processes take about 4MB of RAM.
> >Then there's the amount of memory used by the kernel on top
> >of that.
> 
> Oh, okay.

Kernel itself takes also ~4MB:
----
[    0.000000] Memory: 10276k/10276k available (2032k kernel code, 1920k 
data, 108k init)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0x00284730 - 0x00284b30   (   1 KiB)
[    0.000000]     kmap    : 0xd0000000 - 0xf0000000   ( 512 MiB)
[    0.000000]     vmalloc : 0x01000000 - 0xd0000000   (3312 MiB)
[    0.000000]     lowmem  : 0x00000000 - 0x00e00000   (  14 MiB)
[    0.000000]       .init : 0x0029f000 - 0x002ba000   ( 108 KiB)
[    0.000000]       .text : 0x00001000 - 0x001fc0ee   (2029 KiB)
[    0.000000]       .data : 0x001feaf0 - 0x0029edac   ( 641 KiB)
[    0.000000]       .bss  : 0x00284500 - 0x0029edac   ( 107 KiB)
----


> >Are there some processes at bootup which dirty MBs of memory
> >at bootup and which quit before login (as I saw no such thing),
> >or which memory map very large files?
> 
> I don’t think so.
> 
> >If not, I think bootup should fit well into 14MB (ST-RAM). :-)
> 
> Right. On the other hand, I heard rumours that Linux needs
> TT-RAM to function at all, and that ST-RAM wasn’t available
> to applications. That’s another reason I wanted the mailing
> list in the loop, to confirm, deny or possibly fix that ;-)

Aranym seems always to enable full 14MB of ST-RAM, which is also stated
in its documentation:
	http://wiki.aranym.org/manual#ram

I set FastRAM in Aranym to zero (which removed the other DMA zone node
kernel reports at boot) and removed the swap from your image, and it
still booted fine.

So, it seems that it's possible to run just with ST-RAM.  I would say
that one needs at least 8MB + swap, or 14MB of RAM.


With 14MB of ST-RAM, no swap, the user space situation at the end of boot
and logging in, is following according to /proc/meminfo:

* user-space has 10MB available, of which 5MB is in buffers and caches
  and 0.9MB is totally unused (free).
* 5MB of memory is marked active, of which half is in anon allocs
  and half is file based.
* 1.5MB is in kernel slabs, of which only 0.3MB is reclaimable.

Doing:
	echo 1 /proc/sys/vm/drop_caches

And letting the system idle for a while so that necessary
code and file pages are paged back in, changes that a bit:

* 2MB free, with 2MB in caches.
* 3.2MB active, mostly anon.
* slab reclaimable grew to 2.1MB.

So there are only few MB of RAM freely available for running something
extra.  -> 14MB is indeed minimum to do anything useful.


> >> The installation process is especially memory sensitive, as
> >> it involves a ramdisk of lots of megs…
> >
> >Could you point to documentation describing it more in detail?
> 
> There’s none really, but you have a kernel and an initrd,
> and the entire process runs from RAM. Wouter even did build
> d-i images, but they’re not yet usable for various reasons.

I would think use of a pre-installed Debian rootfs image to be
more appropriate for Atari TT.

I remember checking memory usage during e.g. Ubuntu installation
and there are processes that take a lot of RAM (also others than
the Ubuntu specific GUI installer :-)).



	- Eero


Reply to: