Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 4 Feb 2008 13:40:31 +1100 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        Alexander Motin <mav@freebsd.org>
Cc:        freebsd-hackers@freebsd.org, Robert Watson <rwatson@freebsd.org>, freebsd-performance@freebsd.org, Julian Elischer <julian@elischer.org>
Subject:   Re: Memory allocation performance
Message-ID:  <20080204133437.T63947@delplex.bde.org>
In-Reply-To: <47A650DA.8020908@FreeBSD.org>
References:  <47A25412.3010301@FreeBSD.org> <47A25A0D.2080508@elischer.org> <47A2C2A2.5040109@FreeBSD.org> <20080201185435.X88034@fledge.watson.org> <47A43873.40801@FreeBSD.org> <20080202095658.R63379@fledge.watson.org> <47A4E934.1050207@FreeBSD.org> <47A4F1AF.9090306@FreeBSD.org> <47A650DA.8020908@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 4 Feb 2008, Alexander Motin wrote:

> Kris Kennaway wrote:
>> You can look at the raw output from pmcstat, which is a collection of 
>> instruction pointers that you can feed to e.g. addr2line to find out 
>> exactly where in those functions the events are occurring.  This will often 
>> help to track down the precise causes.
>
> Thanks to the hint, it was interesting hunting, but it shown nothing. It hits 
> into very simple lines like:
> bucket = cache->uc_freebucket;
> cache->uc_allocs++;
> if (zone->uz_ctor != NULL) {
> cache->uc_frees++;
> and so on.
> There is no loops, there is no inlines or macroses. Nothing! And the only 
> hint about it is a huge number of "p4-resource-stall"s in those lines. I have 
> no idea what exactly does it means, why does it happens mostly here and how 
> to fight it.

Try profiling it one another type of CPU, to get different performance
counters but hopefully not very different stalls.  If the other CPU doesn't
stall at all, put another black mark against P4 and delete your copies of
it :-).

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080204133437.T63947>