[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 4/4] tools/xenalyze: Allow automatic resizing of sample buffers
On Mon, Aug 8, 2016 at 6:11 PM, anshul makkar <anshul.makkar@xxxxxxxxxx> wrote: > On 08/08/16 10:54, George Dunlap wrote: >> >> Rather than have large fixed-size buffers, start with smaller buffers >> and allow them to grow as needed (doubling each time), with a fairly >> large maximum. Allow this maximum to be set by a command-line >> parameter. >> >> Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxx> >> --- >> CC: Ian Jackson <ian.jackson@xxxxxxxxxx> >> CC: Wei Liu <wei.liu2@xxxxxxxxxx> >> CC: Dario Faggioli <dario.faggioli@xxxxxxxxxx> >> CC: Anshul Makkar <anshul.makkar@xxxxxxxxxx> >> --- >> tools/xentrace/xenalyze.c | 95 >> +++++++++++++++++++++++++++++++++-------------- >> 1 file changed, 68 insertions(+), 27 deletions(-) >> >> diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c >> index 455cbdf..a4d8823 100644 >> --- a/tools/xentrace/xenalyze.c >> +++ b/tools/xentrace/xenalyze.c >> @@ -44,7 +44,8 @@ struct mread_ctrl; >> #define QHZ_FROM_HZ(_hz) (((_hz) << 10)/ 1000000000) >> >> #define ADDR_SPACE_BITS 48 >> -#define DEFAULT_SAMPLE_SIZE 10240 >> +#define DEFAULT_SAMPLE_SIZE 1024 >> +#define DEFAULT_SAMPLE_MAX 1024*1024*32 >> #define DEFAULT_INTERVAL_LENGTH 1000 >> > >> s->event_count++; >> >> if (!c) >> return; >> >> if(opt.sample_size) { >> - int lap = (s->count/opt.sample_size)+1, >> - index =s->count % opt.sample_size; >> - if((index - (lap/3))%lap == 0) { >> - if(!s->sample) { >> - s->sample = malloc(sizeof(*s->sample) * opt.sample_size); >> - if(!s->sample) { >> - fprintf(stderr, "%s: malloc failed!\n", __func__); >> - error(ERR_SYSTEM, NULL); >> - } >> + if (s->count >= s->sample_size >> + && (s->count == 0 >> + || opt.sample_max == 0 >> + || s->sample_size < opt.sample_max)) { >> + int new_size; >> + void * new_sample = NULL; >> + >> + new_size = s->sample_size << 1; > > Sorry for my ignorance here, but why we have chosen to double the size. > Can't we increase by fixed size X where X < double size. Are we sure that we > will be able to fully utilize the double sized buffer. Well we're sure it will be at least 50% utilized. :-) Also remember that we're in userspace here, so no physical memory will be allocated until the process actually writes to the virtual memory anyway. The main goal is to balance virtual memory usage against the cost of reallocation (which will probably involve copying all the data from the old buffer into the new buffer), and there's no point in having a really complicated algorithm until we find cases where the simple algorithm is a problem. -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |