From e25f7b7182a08c17becb104fb03fd8f180aad815 Mon Sep 17 00:00:00 2001 From: sgunderson Date: Thu, 17 Aug 2000 21:55:08 +0000 Subject: [PATCH] Added a note that BSD sendfile() isn't utilized yet; added an extended discussion on problems with mmap() and the 32-bit 2GB address space. --- README | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/README b/README index f2d4e6f..9a39e31 100644 --- a/README +++ b/README @@ -112,11 +112,20 @@ if you were serving the same 128MB file 10 times, top would claim you used over a gigabyte of memory, still only a couple of megabytes would be used at most, as cache. If you ran out of memory, this could actually shrink to zero. It's just that the kernel tries to be more effective (and it succeeds) by reducing -the number of reads, and instead reading larger chunks at once. - -If sendfile() support is enabled, and the circumstances allow it (binary mode -downloading), BetaFTPD will not mmap() at all, bringing the memory total down -to a more realistic value. +the number of reads, and instead reading larger chunks at once. Actually, for +32-bit architectures, if you serve large several large files, you might get a +problem with hitting the 2GB address space (every mmap() counts towards this +limit, it appears). The solutions are many: Use sendfile() (see below), do +without mmap, or enable high memory support in your kernel (at least Linux +2.3/2.4 can do this at compile time). For most of us, though, this will never be +a problem, just be aware of it if you're doing a benchmark, for instance. Future +versions of BetaFTPD might just mmap() once per file (instead of once per +transfer per file), but this is probably more problems than it's worth. + +If sendfile() support is enabled (note that only Linux sendfile() is working at +the moment, BSD sendfile() is detected but not utilized), and the circumstances +allow it (binary mode downloading), BetaFTPD will not mmap() at all, bringing +the memory total down to a more realistic value. Bragging: -- 2.39.2