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