Linux-kernel mailing list archive 1999-32,: Re: clustering page-ins

# Re: clustering page-ins

Jamie Lokier (lkd@tantalophile.demon.co.uk)
Thu, 12 Aug 1999 10:47:27 +0200

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Andreas Schwab: "Re: info format (was Re: Linux 2.2.11pre4)"
- Previous message: Olle Lindroos: "IPIP Tunnelling"
- In reply to: Dr. Michael Weller: "Re: clustering page-ins"
- Next in thread: Chuck Lever: "Re: clustering page-ins"

Dr. Michael Weller wrote:
> [madvise]
> I was told somehow the origins of this function might be BSD, so it might
> be worthwhile to support. I saw it in many unixes but it is usually
> documented to have no effect at all.

My vote is forget madvise() until we've seen how well the kernel
performs with Chuck's patches. MADV_DONTNEED may well come in handy,
but I'm skeptical about MADV_SEQUENTIAL/MADV_RANDOM.

The read-ahead and clustering mechanism should notice random
vs. sequential very easily, and because the kernel can deduce how fast
the disk is relative to the app., it can tune the windows sizes
optimally as well.

For that sort of self-tuning algorithm we've been discussing,
madvise(MADV_SEQUENTIAL) makes no difference to the paging algorithm:
you have to track faults in order to discover the tuning parameters
anyway. And the app can't provide that info statically because it
doesn't know how fast the disk/network is.

Which gives me a thought. Is there's an algorithm to discover the
optimal random-access readaround cluster size, analogous to the
sequential readahead window algorithm?

-- Jamie

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

- Next message: Andreas Schwab: "Re: info format (was Re: Linux 2.2.11pre4)"
- Previous message: Olle Lindroos: "IPIP Tunnelling"
- In reply to: Dr. Michael Weller: "Re: clustering page-ins"
- Next in thread: Chuck Lever: "Re: clustering page-ins"