Re: MM deadlock [was: Re: arca-vm-8...]

Thomas Sailer (sailer@ife.ee.ethz.ch)
Tue, 26 Jan 1999 12:45:08 +0100


Gerard Roudier wrote:

> If you tell me that some system XXX is able to quickly free Mega-Bytes of
> physical contiguous memory at any time when it is asked for such a

Noone said it has to happen quickly, it's entirely useful even if
the calling process (and possibly others) will sleep for 10secs.
These allocations are very uncommon, but nevertheless sometimes
necessary for some device (drivers).

> brain-deaded allocation, then for sure, I will never use system XXX,
> because this magic behaviour seems not to be possible without some
> paranoid VM policy that may affect badly performances for normal stuff.

You may well call the devices that need this broken, the problem
is that they are in rather widespread use.

If we don't find an algorithm that doesn't affect preformance for
the normal stuff, (why would something like selecting
a memory region and forcing everything that's currently in the
way to be swapped out not work?), then we should probably have
a special pool for these "perverse" mappings.

But I think there's a rather generic problem: how are you going
to support 32bit PCI busmasters in machines with more than
4Gig main memory? It's conceptually the same as how are you
going to support ISA DMA with more than 16Meg main memory.

32bit only PCI busmasters are very common these days, I don't
know a single PCI soundcard that can do 64bit master (or even slave)
cycles. Also, all PCI soundcards I know which have a hardware
wavetable synth (without sample ROM) require ridiculously
large contiguous allocations (>= 1M) for the synth to work.

> Anything that requires more that 1 PAGE of physical memory at a time on
> running systems is a very bad thing in my opinion. The PAGE is the only

Ok, then remove any soundcard from your system. That might be acceptable
for you, but probably not for 90% of the Linux users.

Tom

-
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/