[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b21f8390707310937i5f90fa2rae650221b3ff4880@mail.gmail.com>
Date: Wed, 1 Aug 2007 02:37:03 +1000
From: "Matthew Hawkins" <darthmdh@...il.com>
To: "Nick Piggin" <nickpiggin@...oo.com.au>
Cc: "Ray Lee" <ray-lk@...rabbit.org>,
"Jesper Juhl" <jesper.juhl@...il.com>,
linux-kernel@...r.kernel.org, "ck list" <ck@....kolivas.org>,
linux-mm@...ck.org, "Paul Jackson" <pj@....com>,
"Andrew Morton" <akpm@...ux-foundation.org>
Subject: Re: [ck] Re: -mm merge plans for 2.6.23
On 7/25/07, Nick Piggin <nickpiggin@...oo.com.au> wrote:
> I guess /proc/meminfo, /proc/zoneinfo, /proc/vmstat, /proc/slabinfo
> before and after the updatedb run with the latest kernel would be a
> first step. top and vmstat output during the run wouldn't hurt either.
Hi Nick,
I've attached two files with this kind of info. Being up at the cron
hours of the morning meant I got a better picture of what my system is
doing. Here's a short summary of what I saw in top:
beagleindexer used gobs of ram. 600M or so (I have 1G)
updatedb didn't use much ram, but while it was running kswapd kept on
frequenting the top 10 cpu hogs - it would stick around for 5 seconds
or so then disappear for no more than 10 seconds, then come back
again. This behaviour persisted during the run. updatedb ran third
(beagleindexer was first, then update-dlocatedb)
I'm going to do this again, this time under a CFS kernel & use Ingo's
sched_debug script to see what the scheduler is doing also.
Let me know if there's anything else you wish to see. The running
kernel at the time was 2.6.22.1-ck. There's no slabinfo since I'm
using slub instead (and I don't have slub debug enabled).
Cheers,
--
Matt
Download attachment "beaglecron.ck" of type "application/octet-stream" (4539 bytes)
Download attachment "updatedbcron.ck" of type "application/octet-stream" (5382 bytes)
Powered by blists - more mailing lists