aboutsummaryrefslogtreecommitdiff
path: root/modutils
diff options
context:
space:
mode:
Diffstat (limited to 'modutils')
-rw-r--r--modutils/insmod.c13
1 files changed, 8 insertions, 5 deletions
diff --git a/modutils/insmod.c b/modutils/insmod.c
index f45a59465..3fbb02b75 100644
--- a/modutils/insmod.c
+++ b/modutils/insmod.c
@@ -4235,12 +4235,15 @@ static int insmod_ng_main(int argc ATTRIBUTE_UNUSED, char **argv)
4235 } 4235 }
4236 4236
4237#if 0 4237#if 0
4238 /* Any special reason why mmap? It isn't performace critical... */ 4238 /* Any special reason why mmap? It isn't performance critical. -vda */
4239 4239 /* Yes, xmalloc'ing can use *alot* of RAM. Don't forget that there are
4240 /* yes, xmalloc'ing can use *alot* of RAM. Don't forget that there are
4241 * modules out there that are half a megabyte! mmap()ing is way nicer 4240 * modules out there that are half a megabyte! mmap()ing is way nicer
4242 * for small mem boxes, i guess. 4241 * for small mem boxes, i guess. */
4243 */ 4242 /* But after load, these modules will take up that 0.5mb in kernel
4243 * anyway. Using malloc here causes only a transient spike to 1mb,
4244 * after module is loaded, we go back to normal 0.5mb usage
4245 * (in kernel). Also, mmap isn't magic - when we touch mapped data,
4246 * we use memory. -vda */
4244 int fd; 4247 int fd;
4245 struct stat st; 4248 struct stat st;
4246 unsigned long len; 4249 unsigned long len;