Re: [PATCH 10/15] mm: atomic64 page counts

[Andrew Morton]

Hugh Dickins <hugh@xxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/