Re: 2.6.0-test3-mm1

Martin J. Bligh
2003-08-11T22:47:39Z

> On Mon, Aug 11, 2003 at 01:17:04PM -0700, Martin J. Bligh wrote:
>> Buggered if I know what Letext is doing there ???
>> 6577 3.9% total
>> 1157 0.0% Letext
>> 937 0.0% direct_strnlen_user
>> 748 440.0% filp_close
>> 722 21.2% __copy_from_user_ll
>> 610 2.6% page_remove_rmap
>> 492 487.1% file_ra_state_init
>> 452 12.4% find_get_page
>> 405 7.6% __copy_to_user_ll
>> 402 28.6% schedule
>> 386 0.0% kpmd_ctor
>> 348 4.4% __d_lookup
>> 310 16.6% atomic_dec_and_lock
>> 300 174.4% may_open
>
> You can figure out what it is by reading addresses directly out of
> /proc/profile that would correspond to it (i.e. modifying readprofile)
> and correlating it with an area of text in a disassembled kernel.

Was more interested in which patch screwed up the profiling really ...
I suspect someone knows already ;-)

> kpmd_ctor() is unusual; how many runs does this profile represent?
> Does it represent the first run? Ideally, all your kernel pmd's should
> be cached. If it's not the first run, then logged slab cache statistics
> would be interesting to determine whether this is still the case even
> while effective cacheing is going on or whether slab cache reaping is
> blowing these things away (i.e. either ineffective cacheing is happening
> or for some reason cacheing them isn't good enough).

It's the average of 5 runs, after an initial warmup run which is discarded.

> Of course, it would probably be better to deal with first-order effects
> first. On that note, how many profile hits total? How many runs is this
> summed together from? Which run is this (numerically in the order you
> ran them) if the profiles are from only one run?

See above.

M.