On Mon, Aug 11, 2003 at 01:17:04PM -0700, Martin J. Bligh wrote:

quoted

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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>