lkml.org 
[lkml]   [1998]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Thread implementations...
    From
    Date
    >>>>> "RG" == Richard Gooch <Richard.Gooch@atnf.CSIRO.AU> writes:

    RG> If we get madvise(2) right, we don't need sendfile(2), correct?

    It looks like it from here. As far as madvise goes, I think we need
    to implement madvise(2) as:

    enum madvise_strategy {
    MADV_NORMAL,
    MADV_RANDOM,
    MADV_SEQUENTIAL,
    MADV_WILLNEED,
    MADV_DONTNEED,
    }
    struct madvise_struct {
    caddr_t addr;
    size_t size;
    size_t strategy;
    };
    int sys_madvise(struct madvise_struct *, int count);

    With madvise(3) following the traditional format with only one
    advisement can be done easily. The reason I suggest multiple
    arguments is that for apps that have random but predictable access
    patterns will want to use MADV_WILLNEED & MADV_DONTNEED to an optimum
    swapping algorigthm.

    And for that you will probably need multiple address ranges. The
    clustering comunity has a similiar syscall implemented for programs
    whose working set size exceeds avaiable memory. Except it has
    strategy hardwired to MADV_WILLNEED.

    However someone needs to look at actuall programs to see which form
    is more practical to implement, in the kernel.

    Of course all I know about madvise I just read in the kernel source so
    I may be totally off...

    Eric

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu

    \
     
     \ /
      Last update: 2005-03-22 13:43    [W:0.044 / U:90.540 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site