* MP singular...@gmail.com schrieb:
We could have some get that file into memory call, that will try to
use mmap if possible and store pointer to freeing the block (that
would call munmap, free or some other method depending on how the
block was acquired)
Exactly :)
The actual fs (and only
I believe the idea is to be able to view parts of huge file without
loading them to RAM first. (for really big files, they may not even
fit in RAM.)
Some really big files won't fit even in virtual memory. For example on
32bit architectures (like commonly used i386) you have 2gb usable
virtul
On Sat 2008-12-27 21:43:53, Enrico Weigelt wrote:
* Enrico Weigelt weig...@metux.de schrieb:
Hi folks,
I really wonder whether the mmap() stuff is still needed at all.
It doesnt seem to be really used anywhere.
Ups, didn't look hard enough (just scanned the vfs subdir) ;-O
a) cmd.c: compare_files() - it uses the mmap() call directly
(w/o going over mcvfs), and it seems to work on local files
only. wouldn't it make sense to let it run via mcvfs ?
b) view.c: it tries to mmap() in the file, obviously to let the
kernel do all the loading.
BUT:
* Miguel de Icaza mig...@novell.com schrieb:
Hi,
mmap is more efficient, because the kernel can throw those pages out at
any time (as it knows what the backing store for the file is), so under
memory pressure it can alleviate the system load easily.
Absolutely right, but we have to keep in
* Enrico Weigelt weig...@metux.de schrieb:
Hi folks,
I really wonder whether the mmap() stuff is still needed at all.
It doesnt seem to be really used anywhere.
Ups, didn't look hard enough (just scanned the vfs subdir) ;-O
Okay, there're mainly two mmap()-using places:
a) cmd.c:
