Messages in this thread | | | Date | Wed, 18 Aug 2004 16:16:58 -0700 | From | "David S. Miller" <> | Subject | Re: Does io_remap_page_range() take 5 or 6 args? |
| |
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. - 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/
| |