Return to BSD News archive
Newsgroups: comp.os.386bsd.questions Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!decwrl!csus.edu!netcom.com!thinman From: thinman@netcom.com (Technically Sweet) Subject: Re: FreeBSD: Does it solve the 16M problem Message-ID: <thinmanCDBAAJ.LqG@netcom.com> Organization: International Foundation for Internal Freedom References: <g89r4222.747163756@kudu> <26itba$eaj@pdq.coe.montana.edu> <CD2qLA.vq@autelca.ascom.ch> <JKH.93Sep9162315@thrush.lotus.com> <270nep$oa@belfast.dcd.wa.gov.au> Date: Mon, 13 Sep 1993 21:27:55 GMT Lines: 36 There are no EISA bus sound cards. There probably never will be, because the required bus transfer rates are so low that manufacturers will not perceive the need. Therefore, sound I/O will never work in >16M machines. Capiche? Generic bounce buffers (copying data around on each transfer) are clearly unpleasant. That's not how you do it. Instead: Observations: Programs that do I/O transfers almost always reuse the same RAM in their address space for successive transfers. Because of virtual memory, programs that do I/O transfers use large contiguous address space which is unfortunately many small physical address chunks. This slows down I/O, because the driver has to keep starting small DMA chunks. Technique: 1) normal ram allocation tries to use RAM above 16M. 2) program does a DMA transfer of X bytes across X+1 pages. 3) system allocates X+1 pages (contiguousity attempted) below 16M. 4) system copies all data from original buffers to new buffer. 5) system remaps user process space from old buffers to new buffer. 6) system marks new buffer "leave this alone as long as you can". 7) thereafter, I/O transfers run smoothly with no copying. Yeah, yeah, the RAM handlers won't let you do it at all. -- Lance Norskog thinman@netcom.com Data is not information is not knowledge is not wisdom.