Hugh Dickins <[email protected]> wrote:
>
> Page count and page mapcount might overflow their 31 bits on 64-bit
> architectures, especially now we're refcounting the ZERO_PAGE. We could
> quite easily avoid counting it, but shared file pages may also overflow.
>
> Prefer not to enlarge struct page: don't assign separate atomic64_ts to
> count and mapcount, instead keep them both in one atomic64_t - the count
> in the low 23 bits and the mapcount in the high 41 bits. But of course
> that can only work if we don't duplicate mapcount in count in this case.
>
> The low 23 bits can accomodate 0x7fffff, that's 2 * PID_MAX_LIMIT - 1,
> which seems adequate for tasks with a transient hold on pages; and the
> high 41 bits would use 16TB of page table space to back max mapcount.
hm. I thought we were going to address this by
a) checking for an insane number of mappings of the same page in the
pagefault handler(s) and
b) special-casing ZERO_PAGEs on the page unallocator path.
That'll generate faster and smaller code than adding an extra shift and
possibly larger constants in lots of places.
It's cleaner, too.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
