Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!haven.umd.edu!uunet!mcsun!Germany.EU.net!gmd.de!olymp!sfb256!volker
From: volker@sfb256.iam.uni-bonn.de ( Volker A. Brandt )
Subject: Re: Julian's 1542B driver and > 16MB
Message-ID: <1993Mar24.125033.18162@olymp.informatik.uni-bonn.de>
Sender: usenet@olymp.informatik.uni-bonn.de
Organization: Applied Math, University of Bonn, Germany
References: <1993Mar22.091308.18241@qualcomm.com> <1993Mar23.021251.2245@fcom.cc.utah.edu>
Date: Wed, 24 Mar 1993 12:50:33 GMT
Lines: 35
In article <1993Mar23.021251.2245@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>I *badly* fixed this problem for myself as a study in the feasability of
>fixing it at all.
[...]
>The place to "start building" is in the VM routines; we need to be able to
>specify whether "cachable" is set and whether the allocator needs to get its
>memory from below 16M for a particular (DMA buffer) allocation.
>
>Basically, it fits very well into a split memory pool arangement, sort of like
>the difference between "fast" and "chip" RAM on the Commodore Amiga. We
>need to ensure chip RAM (RAM below 16M) for DMA devices on ISA machines.
This sounds OK to me, if a little clunky. I hat thought that it might be
squeezed into the buffer cache routines, but unfortunately I don't know enough
about the inner workings of 386bsd yet ...
I would like to state two things:
(1) A cludge solution is better than no solution.
(2) Lets all work together on one solution instead of several mutually
exclusive ones.
I guess that the overhead of making sure that buffers are below 16 M is less
than the performance gain through more [real] memory.
-- Volker
--
----------------------------------------------------------------------------
Bitnet: UNM409@DBNRHRZ1 Volker A. Brandt
Internet: volker@sfb256.iam.uni-bonn.de Angewandte Mathematik
Phone: +49 228 73 3427 (Bonn, Germany)