On 7/26/07, Ingo Molnar <mingo@elte.hu> wrote:
>
> --- /etc/cron.daily/mlocate.cron.orig
> +++ /etc/cron.daily/mlocate.cron
> @@ -1,4 +1,7 @@
> #!/bin/sh
> nodevs=$(< /proc/filesystems awk '$1 == "nodev" { print $2 }')
> renice +19 -p $$ >/dev/null 2>&1
> +PREV=`cat /proc/sys/vm/vfs_cache_pressure 2>/dev/null`
> +echo 0 > /proc/sys/vm/vfs_cache_pressure 2>/dev/null
> /usr/bin/updatedb -f "$nodevs"
> +[ "$PREV" != "" ] && echo $PREV > /proc/sys/vm/vfs_cache_pressure
> 2>/dev/null
> _______________________________________________
> http://ck.kolivas.org/faqs/replying-to-mailing-list.txt
> ck mailing list - mailto: ck@vds.kolivas.org
> http://vds.kolivas.org/mailman/listinfo/ck


uhm... pardon my ignorance, but, doesn't this hack create a possible race
condition?
Ie, this job starts, and while updatedb runs some other app/script (let's
call it Gort) pokes with vfs_cache_pressure (saving 10000, as it's the
current value), then updatedb finishes, and then a while after that Gort
stops, "restoring" vfs_cache_pressure to 10000 instead of $PREV?

What we _really_ want is an updatedb that
> does not disturb the dcache.
>
just a thought, the problem seems (to me, a mere mortal at best) to be that
the functions/program doing the magic messes up caches. Wouldn't the
easiest/obvious solution/hack be to use/write an "uncached_" version of
those functions/apps? (or one that just reads the cache, but never upsets it
by writing to it). Or is that impossible/impractical for some reason? (or
worse yet, have I completely missed the point?)

-- 
... a professor saying: "use this proprietary software to learn computer
science" is the same as English professor handing you a copy of Shakespeare
and saying: "use this book to learn Shakespeare without opening the book
itself.
- Bradley Kuhn