> I can only agree.
> This seems to be reasonable. But I suggest to investigage
> the other ways further. Just to be fair to all solutions and to
> have a good, instead of a "political" solution. I argumented
> also for investigation of all solutions when the "everything
> in user area" arguments came.
>
> But as I told in another mail: I want to investigate the
> driver buffer solution first:
>
> I found out that the size of DMA memory is, for example
> also limited for the SB 128 PCI card by 256MB. And with
> 256MB sound DMA buffer I still have dropouts under disk
> load. So just enlarging the DMA buffer is not sufficient as
> solution.
You _DONT_ have 256MB sound DMA buffer. Apply this one and look how
much you _really_ have.
diff -u clean//drivers/sound/dmabuf.c linux/drivers/sound/dmabuf.c
--- clean//drivers/sound/dmabuf.c Wed Dec 23 11:16:12 1998
@@ -87,6 +87,7 @@
if (start_addr == NULL)
dmap->buffsize /= 2;
}
+ printk( "Sound: allocated %dK buffer\n", dmap->buffsize / 1024 );
if (start_addr == NULL) {
printk(KERN_WARNING "Sound error: Couldn't allocate DMA buffer\n");
> Is there already some 4K linklist of buffers system in the
> kernel that can be used (code reuse is a good weapon
> aggainst kernel bloat)? I guess that the buffer cache is
> too much filesystem related.
Take a look at sound drivers, they already subdivide DMA buffer into
smaller chunks (dmap->nbufs, ...). _Maybe_ it would be possible to
make these chunks physically non-contignuous... (It is _not_ trivial,
I took a look myself).
Pavel
-- I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/