[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.142 / U:2.180 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site