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

MOLNAR Ingo
1999-01-26T15:35:24Z

On Tue, 26 Jan 1999 yodaiken@chelm.cs.nmt.edu wrote:

> What's the benefit? If you need big chunks of physical memory, then you
> obviously are willing to sacrifice efficient use of every last byte.

no, what i want to have is support for on-demand shared-physical-memory
hardware. Resource management. Alan has listed a few examples, and the
list is not expected to get smaller. You are right, if we want to have big
chunks of physical memory then we'll allocate it on reboot.

i dont think it's correct to say: 'anything that cannot be segmented in
the physical memory space with page granularity, is considered to be
broken in this regard and is not guaranteed to be 100% supported by the
Linux architecture'.

> > yes it restricts and complicates the way kernel subsystems can allocate
> > buffers, but we _have_ to do that iff we want to solve the problem 100%.
>
> So for that last 10% of "solve" we introduce a lot of complexity into
> every subsystem?

no, as i pointed it out:

> Also, it must have only very limited 'subsystem-side' complexity to not
> hinder development. [...]

plus, i'd like to point out that if we do something, we preferredly want
to do it 100% correct, especially if the 'packet loss' is visible by
user-space as well. But i'm not at all requesting it:

> the toughest part is the 'moving' stuff, which is not yet present and
> hard/impossible to implement in a clean and maintainable way.
^^^^^^^^^^---(this might as well be the case)

-- mingo

--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/