Re: Thread implementations...

[ebiederm+eric@npwt.net (Eric W. Biederman)]

>>>>> "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