Re: Does io_remap_page_range() take 5 or 6 args?

[William Lee Irwin III]

On Wed, Aug 18, 2004 at 02:30:29PM -0700, David S. Miller wrote:
>> Does not work on a system who has more physical address bits
>> than 32 + PAGE_SHIFT
>> Sparc32 does not fall into this category... but some other
>> might.

On Wed, Aug 18, 2004 at 02:40:26PM -0700, William Lee Irwin III wrote:
> All extant systems of this category I'm aware of are 32-bit kernels on
> 64-bit machines, which we don't really support. Also, the assumption
> that physical addresses are bounded by 1ULL << (BITS_PER_LONG + PAGE_SHIFT)
> is made broadly elsewhere, particularly in pfn_to_page() and the like.
> Making this assumption in remap_page_range() and io_remap_page_range()
> would save the overhead of passing additional arguments and/or passing
> 64-bit arguments on 32-bit machines. Using pgoff_t for pfn's may prove
> useful for such systems, but it's highly doubtful the kernel will ever
> be made clean for such or that they'll ever be brought to a usable state.

Or, if not pgoff_t, introduce a pfn_t for this purpose, an unsigned
arithmetic type of architecture-dependent width (such systems may not
want 64-bit page indices and the like for various reasons). But
exhibiting a system with the need for such is yet to be done, and in
fact, even with a 32B struct page, 16TB RAM (the minimum required to
trigger more physical address bits >= BITS_PER_LONG + PAGE_SHIFT) has
a 128GB mem_map[] with 4KB pages, an 8GB mem_map[] with 64KB pages,
and so will have far, far deeper support issues than pfn overflows.
Even supposing a kernel could be made to boot and the like, the massive
internal fragmentation from using a large enough emulated PAGE_SIZE to
get mem_map[] to fit within virtualspace will surely render such a
machine completely useless, likely to the point of being unable to run
userspace, or panicking much earlier from boot-time allocation failures.

-- wli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/