Messages in this thread | | | Date | Tue, 26 Jan 1999 16:21:30 +0100 (CET) | From | MOLNAR Ingo <> | Subject | Re: MM deadlock [was: Re: arca-vm-8...] |
| |
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 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/
| |