On Sat, 3 Mar 2007 20:16:09 -0500 "Lee Revell" <[EMAIL PROTECTED]> wrote:
> On 3/3/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > The tool uses an LD_PRELOAD hack to intercept glibc's read(), pread(), > > write(), pwrite(), close() and dup2() functions. pagecache control is done > > via posix_fadvise() and sync_file_range(). > > > > How could this have any effect on the updatedb problem? updatedb does > not read() anything, it just open()s and stat()s every file on the > disk. > err, good point. _one_ of those dang things which goes off when you've stayed up too late does a lot of pagecache IO, not sure which one. Maybe rpmq? But I'd expect that to be doing direct-io. But yes, updatedb's pagecache usage will be mainly metadata, and this tool doesn't address metadata pagecache, although it could do so. <does an updatedb on a modest system> It instantiated 5MB of pagecache and 20MB of slab, took about one minute. <runs all the other things in /etc/cron.daily> rpm uses rather a lot of pagecache. So yes, it looks like updatedb is a slab problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/