Re: [BK PATCH 2.5] Introduce 64-bit versions of PAGE_{CACHE_,}{MASK,ALIGN}

Linus Torvalds (torvalds@transmeta.com)
Sun, 28 Jul 2002 16:26:49 -0700 (PDT)


On Sun, 28 Jul 2002, Anton Altaparmakov wrote:
>
> Why should I need to bother with index/offset? It is much more natural to
> work with bytes.

Two major reasons:
- the page cache works with index/offset, and that should be your first
priority, since the page cache is all that matters from a performance
standpoint.
- gcc is known to be broken with 64-bit stuff on 32-bit platforms, and
minimizing the use of "long long" minimizes the risk of hitting bugs.

> Also the page cache limit of 32-bit index is IMO not good and needs to be
> removed.

Dream on. It's good, and it's not getting removed. The "struct page" is
size-critical, and also correctness-critical (see above on gcc issues).

We're not moving to a 64-bit index for the next few years. We're a lot
more likely to make PAGE_SIZE bigger, and generally praying that AMD's
x86-64 succeeds in the market, forcing Intel to make Yamhill their
standard platform. At which point we _could_ make things truly 64 bits
(the size pressure on "struct page" is largely due to HIGHMEM, and gcc
does fine on 64-bit platforms).

But that's certainly years away.

Linus

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