Re: HAVE_MMAP still necessary ?

* Miguel de Icaza <miguel novell com> schrieb:


> 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 mind, that it's only 
supported on some filesystems (not even all local ones). So we
need some clean way to handle it. 

The current implementation is quite unclean, sometimes called mcvfs's
mmap, sometimes the libc's one. That should really be cleaned up.

> > In case we just want to have an faster way for loading files into 
> > memory (in case it's supported), I suggest some new vfs operation
> > for that, let's call it "loadFile()" - it returns some FILE_DATA
> > structure, containing size, buffer ptr and a callback vector for
> > free'ing. Everyone who wants the whole file (or large blocks) 
> > just uses this call instead of ugly #ifdef's, and it's up to vfs
> > to decide what to do behind the scenes.
> You are trying to invent a bloated replacement for something that the
> kernel can do really well.

My point being, we probably don't really want to have mmap itself,
but an efficient way for getting some file (or large parts of it) 
into memory - that's a totally different requirement, and using
mmap() is just one way to do it (if supported by the underlying fs).

For the (mcfs-)clients this is an additional logic, which should 
be hidden behind the scenes - the individual fs should know best
what to do, once we've introduced an appropriate API call.

BTW: some fs'es (on certain platforms) might find a more clever
way, even if mmap() isn't directly supported (eg. emulating it
in userspace ;-P) - we really should leave this to the fs.

 Enrico Weigelt    ==   metux IT service -
 Please visit the OpenSource QM Taskforce:
 Patches / Fixes for a lot dozens of packages in dozens of versions:

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]