>
> From: Gerard Roudier <groudier@club-internet.fr>
> > On Fri, 22 Nov 1996, Jean Francois Martinez wrote:
> >>> From: Gerard Roudier <groudier@club-internet.fr>
> >>>
> >>> 4) Suggestions:
> >>> A suggestion, for > 16MB systems is to garbage if necessary
> >>> up to 1MB in a pool for ISA/DMA but to keep the kernel simple.
> >>> Kernel modules/drivers that allocate ISA/DMA memory when it
> >>> is not needed are to be reworked (or rewritten).
> >>
> >> Interesting idea. But there are still boxes with less than 16 Meg.
> >> Ah the good old days where Linux was usable with 2 megs and was
> >> advertised as being as being small and mean.
> >
> > At work, we use Linux/X/GNU as development system (about 15 linux
> > stations). 2 megs is probably just enough to load the kernel and
> > kernel is not pageable.
>
> If the machine has enough memory, the kernel should be loaded at
> the 16 MB mark.
>
> > Now imagine a system with 128 MB of RAM and some controller(s)
> > that use(s) ISA/DMA and:
> > - Some processes have locked memory.
> > - Some IOs are being processed. Corresponding memory is locked.
> >
> > (Locked memory CANNOT be swapped).
>
> Could locked memory be moved? The kernel could find something above
> the 16 MB ISA DMA limit, swap that, then move the locked memory up
> there. The locked memory does not get swapped, only moved.
>
> If not, the memory can be moved as the application locks it.
> Whenever mlock is called, the memory gets moved above the 16 MB
> mark before it is actually locked.
Thanks for your suggestion. It is exactly such kind of complex things that
are, in my opinion, quite useless nowadays.
Asking Linus to add such things in the kernel is as pertinent as asking
to still support 80286 CPU (IMHO).
On the other hand , it seems to me that your suggested algorithm is
an elegant way to lose 16 MB of memory in some circumstances.
Perhaps, I donnot have understood it 100%.
> > Imagine now that one load a module that requests
> > (rightly or wronly) ISA/DMAable memory and:
> > - Unfortunately locked pages just preclude this allocation.
> >
> > Managing such situation may complexify the kernel too much.
> > In this case, garbaging 1 MB of memory at startup for ISA/DMA
> > need is probably a good solution.
> >
> > On the other hand, being given that 128/16=8, 87% IOs will need
> > to be double-buffered. Doing DMA in that conditions is in my
> > opinion pretty stupid.
>
> Why double buffer? If the DMA memory allocation is modified to
> move pages around, the kernel can just put everything below the
> 16 MB limit. I guess you could call this delayed double buffering.
> The advantage is that sometimes the copy can be avoided. It would
> be previous allocations that get the copy. There is a chance that
> some previous allocation will be freed, and there is a chance that
> some previous allocation will be ready to discard or swap out.
Thanks again. In my opinion, such complex thing does not change
significantly the probability to have to double buffer ISA/DMA ios.
Now, some real situations (some have been measured, some have been guessed):
- NCR825 + Quantum Atlas Wide = 6,8 MB/sec under Linux
- NCR825 + Quantum Atlas Wide = 3 MB/sec under Win95
(Using supplied driver, since people generally use supplied drivers)
- AHA1542C + Quantum Atlas = 2.? MB/sec under linux
- AHA1542C + Quantum Atlas = 2.? MB/sec under Win95
- System load for IOs = 1542C twice than NCR825 under Linux
- System load for IOs = 1542C about the same than NCR825 under Win95
- French pricing for adapters: 1542C=1500FF, NCR825=650FF
- French pricing for HDs : Quantum Atlas 2.1GB=3000FF,
Good EIDE 2.1GB disk=1500FF
Linux has a very good support of EIDE devices (not FreeBSD).
Linux has very good low-level drivers for PCI SCSI boards.
Linux is able to gain advantage of high-end scsi components as well as
cheap EIDE devices.
I am very happy about the fact than Linux is no more outperformed by
some other famous unices for disk and file system IOs.
I know efforts done while 1.3.X development phase about those improvements.
Suggestion of improvements in order to be better for ISA/DMA is in my
opinion quite irrelevant nowadays.
Gerard.
PS: please, donnot think that I ignore that Sound boards generally use
ISA/DMA.