Re: New module proposal: tracker
- From: Alexander Larsson <alexl redhat com>
- To: Martyn Russell <martyn lanedo com>
- Cc: desktop-devel-list gnome org
- Subject: Re: New module proposal: tracker
- Date: Fri, 06 Nov 2009 20:22:33 +0100
On Fri, 2009-11-06 at 15:01 +0000, Martyn Russell wrote:
> > The seeking is hard to avoid, but there may be ways to readdir stuff
> > without having the result be persistant in the buffer cache, although
> > i'm not sure how posix_fadvise(POSIX_FADV_DONTNEED) can be applied when
> > reading a directory...
>
> Yea. We need to research this a bit more to make sure we are doing
> everything we can. We did try the posix_fadvise() call and it was fine
> on the desktop, but for small devices like the n900, it caused a slow
> down which meant we dropped it.
Hmm, really? In what sense? syscall overhead?
There is one problem with POSIX_FADV_DONTNEED. If you do it on a file
the kernel will drop it from its caches. This is generally what you want
if you just indexed a 100 meg text file that no other app cares about
atm, since it means we won't throw out 100 megs of otherwise useful
caches. However, if you're reading a file that some other app actually
cares about this may be a problem, since you're now ensuring that the
file has to be re-read the next time that app wants to use the file. Not
sure if there is a better way though...
> I should add, we have significantly reduced the number of times we call
> stat() (from 0.6->0.7). Previously we used stat in trackerd, then again
> in tracker-indexer, then did something in tracker-extract (which usually
> involved opening the file). I think we did it several times in some
> cases too. Just looking at our code again, I think I have found a way to
> reduce the calls again :)
While this is good news I don't think multiple consecutive calls to stat
on the same file is a huge problem, as all but the first calls will be
availible in the cache already so won't cause i/o.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]