Re: Beagle CPU usage (was Proposed module: tracker)
- From: Federico Mena Quintero <federico ximian com>
- To: Bastien Nocera <hadess hadess net>
- Cc: Desktop Devel <desktop-devel-list gnome org>
- Subject: Re: Beagle CPU usage (was Proposed module: tracker)
- Date: Tue, 27 Mar 2007 14:52:58 -0600
El mar, 27-03-2007 a las 00:54 +0100, Bastien Nocera escribi� >
> > I implemented your code some time ago in Totem's unstable branch, and I
> > was wondering why movies weren't getting thumbnailed anymore. I couldn't
> > mmap files larger than 256 megs.
[snip]
> FYI, I've modified Totem's code to take into account the input file size
> when thumbnailing a file, so the mmap won't fail, and I get 256 megs of
> real memory (hopefully) to process the file.
>
> Other thumbnailers that need to map large files might have different
> needs (eg. mmap'ing large fonts, or images). The thumbnailers have the
> knowledge to do that, not the libgnomeui code.
Woot, I didn't realize that mmap() would bite us. Maybe RLIMIT_DATA
would serve us better.
What happens with mmap-based allocators like GSlice? I wouldn't want a
runaway, glib-based thumbnailer to bypass RLIMIT_DATA. Does anyone know
what the kernel does?
[/me wonders if thumbnailers are measurably faster by using mmap()
instead of read()...]
[Can you have thumbnailable files that are too large to mmap() even with
a full address space? 8 GB videos on a 32-bit box?]
Federico
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]