hi Benno-
the madvise() patch i posted here a few weeks ago was for comments; it's
not really in any shape to be used. also, to use that code easily,
something will have to be added to glibc in order for user space
applications to invoke madvise like any other system call.
i haven't ported it to the most recent kernels because the new
filemap_nopage has some bugs and needs some changes before adding mmap
read-ahead and madvise, so that area of the code is unstable at the
moment. i hope that reasonable read-ahead and madvise patches will be
available for 2.3 soon.
> Sorry for my ignorance but can someone tell me how
> to use the madvise() syscall for streaming,
> ( which parameters are optimal? )
> I'm now mainly working with mmap() / munmap() segments of files
> into mem, and it works rather well, except for the buffering problem
> mentioned above.
well, first you'd want to mmap the object, and use madvise to tell the
kernel to expect sequential access requests. then, you could use either
munmap or madvise(DONTNEED) to release the parts of the object you've
already accessed. madvise(DONTNEED) is likely to be lighter-weight, in
the sense that it is lazy (only releases pages if the system is running
low) and that it leaves the mapping in place in case the application
decides to come back to that region of the object.
keep in mind, though, that madvise is only "advisory" meaning the kernel
is free to ignore the information provided via madvise. so on some
operating systems, you may see no gains by using it.
> Last question: I'm using RH6.0 , if I run on a 2.3.x kernel + madvise()
> patches, will the compiler compile a program containing the madvise() syscall
> correctly, or do I need to include some special headers or recompile glibc ?
see above -- i don't believe that glibc supports madvise on Linux yet. or
if it does, it is a stub on ia-32. so, in your application, you'll need
to emulate the generic system call code that glibc uses.
- Chuck Lever
-- corporate: <chuckl@netscape.com> personal: <chucklever@netscape.net> or <cel@monkey.org>The Linux Scalability project: http://www.citi.umich.edu/projects/linux-scalability/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/