About pieces.preload.* options

[colinhd8]

What does these options mean:

preload type 0 = Off, 1 = madvise, 2 = direct paging

pieces.preload.type.set = 1
pieces.preload.min_size.set = 262144
pieces.preload.min_rate.set = 5120
and what do they affect?
there is no explain i can fetch by the google, so i post it here.
Thank you.

[rakshasa]

When a piece is to be uploaded to a peer it can preload the piece of the file before it does the non-blocking write to the network. This will not complete the whole piece if parts of the piece is not already in memory, having instead to try again later.

Off means it doesn't do any.

MAdvise means it calls 'madvise' on the file for the specific mmap'ed memory range, which tells the kernel to load it in memory when it gets around to it. Which is hopefully before we write to the network socket.

Direct paging means we 'touch' each file page in order to force the kernel to load it into memory. This can help if you're dealing with very large number of peers and large/many files, especially in a low-memory setting, as you can avoid thrashing the disk where loaded file pages get thrown out before they manage to get sent.

Now if someone would put something like this on the wiki.

[colinhd8]

Thank you for your answer.
1.So if i have a large memory and dealing with very large number of peers and large/many files, the best type of preload is the "Direct paging", right?
2.Through iotop command, i found that rtorrent doesn't cache the read operation(total disk read = actual disk read all the time).
3.As there is a large memory on the system, i want to cache all of the disk operation so protect the disk, i want know how to config it.
4.hould i increase the receive/send buffer?

Thank you.

[stickz]

People with large amounts of system memory should use pieces.preload.type.set = 2. In this instance, I doubled the effectiveness of direct paging by setting pieces.preload.min_rate.set = 50000.

The logic here is to not page when the transfer speed is less than 50kb/s. It's better to let requests from these clients hit the disk, as it's very infrequent and inexpensive on disk i/o.

I ended up doubling the active memory on my system from 18GB to 34GB. You can check active memory by running this command: cat /proc/meminfo | grep ^Active. Shortly afterwards, my transfer speeds also increased.