lkml.org 
[lkml]   [2005]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 10/15] mm: atomic64 page counts
Hugh Dickins <hugh@veritas.com> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-11-10 03:19    [W:0.154 / U:5.976 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site