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

["David S. Miller" <davem@redhat.com>]

On Wed, 18 Aug 2004 15:59:15 -0700
William Lee Irwin III <wli@holomorphy.com> wrote:

> On Wed, Aug 18, 2004 at 03:00:01PM -0700, William Lee Irwin III wrote:
> > 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.
> 
> Given this, will a pfn suffice?

There is an error in the calculations.  16TB "RAM", means "RAM".
On many systems, a large chunk of the physical address space is
taken up by I/O areas, not real memory.

Such areas do not take up mem_map[] array space.

Regardless, I think an "unsigned long" page frame number is sufficient
for now.  Don't even make the new type.