[lkml]   [2005]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 10/15] mm: atomic64 page counts
Hugh Dickins <> 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-11-10 03:19    [W:0.102 / U:31.308 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site