Re: Debian/Linux on Atari TT
Hi,
FYI: Next Hatari version (to be released within a month)
has TT-RAM/32-bit, 030 MMU and 030 instruction+data
cache emulation.
Does somebody have either a readymade:
* ACSI image that should boot in real TT, or
* IDE image that should boot in real Falcon?
(I.e. one that contains bootloader and kernel in the image itself,
instead of kernel being separate like is done with Aranym images.)
I'd like to check whether there are any issues in running
that and see whether I can profile m68k Linux performance
with it, using Hatari's facilities[1] for that:
http://hg.tuxfamily.org/mercurialroot/hatari/hatari/raw-
file/tip/doc/manual.html#Profiling
- Eero
[1] Instruction count & cache miss profling, support
both for CPU & DSP, callgraphs etc.
On torstai 24 tammikuu 2013, Eero Tamminen wrote:
> 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: