On Monday 06 May 2002 21:07, Roman Zippel wrote:
> Hi,
>
> On Mon, 6 May 2002, Daniel Phillips wrote:
>
> > I don't, I observed that in all known instances of config_discontigmem,
> > that linear relationship is preserved.
>
> That's true, but m68k isn't using config_discontigmem. :)
Right. In fact, your two way, phys_to_virt and virt_to_phys mapping makes it
more like config_nonlinear. You don't define the contiguous logical memory
space though, and perhaps that's the reason you need the free_area_init
changes in the patch below.
Your patch preserves a linear relationship between physical and virtual
memory, because you do both the ptov and vtop lookup in the same array. As
such, you don't provide the functionality I provide of being able to fit a
large amount of physical memory into a small amount of virtual memory, and
you can't join all your separate pgdat's into one, as I do. (The latter is
desireable because it allows the memory manager to allocate from one
homogeneous space, reducing the likelihood of zone balancing problems.)
We could, if we want, implement your variable sized memory chunk system with
config_nonlinear. You'd just have to replace the
ulong psection[MAX_SECTIONS]
with:
struct { ulong base; ulong size; } pchunk[MAX_CHUNKS];
and replace the four direct table lookup with loops. Highmem does not need
to be a special case, by the way. Another by the way: you've accidently
repeated the last four lines of mm_vtop. Finally, it looks like your
ZTWO_VADDR hack in mm_ptov would also cease to be a special case, at least,
the special case part would move to the initialization instead of every __va
operation. So you would end up with *zero* special cases in the page
translation functions of page.h.
> ...you only have to take care, that you don't iterate
> with the physical address over a pgdat, this is what the patch below
> fixes, the rest can be hidden in the arch macros and no special config
> options is needed.
You do have a config option, it's CONFIG_SINGLE_MEMORY_CHUNK. You just didn't
attempt to create the contiguous logical address space as I did, so you
didn't need to go outside your arch.
The generic part of config_nonlinear is tiny anyway - only 200 lines, and
might grow to 400 by the time all device driver usage of __pa is reclassified
as either virt_to_phys or virt_to_logical - the latter being a rather nice
distinction to make, even if the mapping is the same don't you think? I.e,
it's like the distinction between pointer and integer: if it's a physical
address you can pass it to dma hardware, for example and if it's logical
you're just using it for accounting.
Whenever it's possible to elevate a per-arch feature to the generic level
without compromising functionality, it should be done, modulo programmer
time, and of course, assuming functionality isn't compromised. At
the generic level, it's easier to document, we get cross-pollination from
improvements developed on different arches, and it's easier to build on.
Going the other way and allowing design features to fray across architectures
takes us in the direction of unmaintainable bloat.
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 14 2002 - 12:00:09 EST