(Incidentally, the 1.3.37 kernel seems much faster for me on this system,
possibly because of more free memory - no big ftape allocations at boot, and
more drivers as modules - or possibly because of the new scheduler and
swapping stuff.)
Not particularly to my surprise (I read the linux-kernel and linux-tape
mailing lists) I found that 1.3.37 no longer has an ftape option. Okay, I
applied the patch to ftape-2.03b that appeared a while back, and voila...
ftape.o wouldn't load!
The log messages I get indicate that it's dynamically allocating the first
two DMA buffers without trouble, but can't get the third. ftape will load
on another system (16 megs ram) just fine - even though there's no tape
drive.
>From the shift-scroll-lock output, it seems that I have plenty of RAM left
(relatively - this computer DOES only have 5 megs, after all) but it's in
tiny chunks of 4 or 8k, for the most part, with one big 64k block. It's my
understanding that ftape allocates 32k in each block, so it makes sense from
this that it would only get the first two.
So, I wrote a program which allocates 5 megs of memory, and ran that one -
this cleared just about everything out of memory, and left me with just
enough big blocks to load ftape successfully. I'm running a backup now, and
it seems to be fine.
However, it's not exactly an optimal solution. I can think of two ways to
fix this:
1) (ideally) Have the kernel do a memory-cleanup to make sure nice, large
blocks are available whenever a DMA memory allocation is made. In a
perfect world, this would also dump relevant portions of the buffer cache
and swap programs out to disk if necessary. (slower is better than
nothing!)
2) (quick hack) Make the kernel always allocate from the smallest possible
blocks of memory. It's my understanding that because we're in protected
mode here, it should be perfectly fine for most uses if we just combine a
bunch of 4k blocks together to get what we want; only DMA memory needs to
be truly contiguous.
This would try to keep the number of tiny little block-fragments down to
a minimum, at least.
Any thoughts? I know little to nothing about the memory manager, though I
have done quite a bit of programming (including DMA under DOS, and the Linux
ARCnet driver) before.
Thanks!
Avery