[lkml]   [1998]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Thread implementations...
    >>>>> "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 {
    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...


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

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