[lkml]   [2002]   [Aug]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: large page patch
    On Thu, Aug 01, 2002 at 05:37:46PM -0700, Andrew Morton wrote:

    diff -Naru linux.lp/arch/i386/kernel/entry.S
    --- Mon Feb 25 11:37:53 2002
    +++ linux.lp/arch/i386/kernel/entry.S Tue Jul 2 15:12:23 2002
    @@ -634,6 +634,10 @@
    .long SYMBOL_NAME(sys_ni_syscall) /* 235 reserved for removexattr */
    .long SYMBOL_NAME(sys_ni_syscall) /* reserved for lremovexattr */
    .long SYMBOL_NAME(sys_ni_syscall) /* reserved for fremovexattr */
    + .long SYMBOL_NAME(sys_get_large_pages) /* Get large_page pages */
    + .long SYMBOL_NAME(sys_free_large_pages) /* Free large_page pages */
    + .long SYMBOL_NAME(sys_share_large_pages)/* Share large_page pages */
    + .long SYMBOL_NAME(sys_unshare_large_pages)/* UnShare large_page pages */

    Must large pages be allocated this way?

    At some point I would like to see code that mmap's large amounts of
    data (over 1GB) and have it take advantage of this once the kernel is
    potentially extended to deal with mapping of large and/or variable
    sized pages backed to disk.

    Also, some scientific applications will malloc(3) gobs of ram, again
    in excess of 1GB, is it unreasonable to expect that the kernel will
    notice large allocations and try to provide large pages sbrk in
    invoked with suitable high values?

    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-03-22 13:27    [W:0.036 / U:21.824 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site