Linux-kernel mailing list archive 1998-25,: Re: Thread implementations...

# Re: Thread implementations...

Eric W. Biederman (ebiederm+eric@npwt.net)
24 Jun 1998 17:00:59 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Chris Wedgwood: "Re: Scheduler fixes"
- Previous message: Richard Hirst: "Re: BUG FIX modules problems"
- In reply to: Richard Gooch: "Re: Thread implementations..."
- Next in thread: Chris Wedgwood: "Re: 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 {
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

- Next message: Chris Wedgwood: "Re: Scheduler fixes"
- Previous message: Richard Hirst: "Re: BUG FIX modules problems"
- In reply to: Richard Gooch: "Re: Thread implementations..."
- Next in thread: Chris Wedgwood: "Re: Thread implementations..."