[<prev] [next>] [day] [month] [year] [list]
Message-Id: <20121015.154436.753507258899505232.davem@davemloft.net>
Date: Mon, 15 Oct 2012 15:44:36 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: a.p.zijlstra@...llo.nl
CC: paulus@...ba.org, mingo@...hat.com, acme@...stprotocols.net,
linux-kernel@...r.kernel.org
Subject: [BUG] Perf refers to garbage events on 32-bit.
When the perf tool is built 32-bit, it uses a sliding window mechanism
to mmap the events from the perf.data file.
However things stop working once we get past 8 times the 32-bit window
size (which is 32MB).
That's because the session code that reads in the events maintains an
array of 8 mmap'd areas, and wraps around to the first, remapping it,
if it runs through the full set of 8 entries.
But this doesn't work since the perf backends maintain references to
the entry pointers (in iterators, etc.). But after a remap, that
entry points to a random location in the newly mmap()'d area.
This means any perf.data file larger than 8 * 32MB cannot be correctly
analyzed by the perf tools on 32-bit.
The best solution is probably to make the mmap array variable size,
trying to map everything in sliding window sized chunks, and fail if
we run out of address space. There are hard dependencies in the perf
code to being able to keep all of the events from a perf.data file
in memory at one time.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists