Context Navigation

Changes between Version 2 and Version 3 of RTSsummaryEvents

v2	v3
37	37	}}}
38	38
39		No idea, TODO.
	39	Ask JaffaCake what does the formula mean:
	40
	41	{{{
	42	(peak_mblocks_allocated * BLOCKS_PER_MBLOCK * BLOCK_SIZE_W - hw_alloc_blocks * BLOCK_SIZE_W) / (1024 * 1024 / sizeof(W_))
	43	}}}
	44
	45	in particular what is the difference between peak_mblocks_allocated and hw_alloc_blocks.
40	46
41	47	{{{
…	…
48	54	(if RequestParGC is not enough to tell seq/par). We don't want to report
49	55	the CPU time, only the elapsed time, and that's fine.
	56	With the current GC events only summarized information is available.
50	57
51	58	{{{
…	…
59	66	the events. Perhaps +RTS -s could be modified to make this figure simpler?
60	67
61		To be continued.
	68	{{{
	69	MUT time (elapsed) GC time (elapsed)
	70	Task 0 (worker) : 0.04s ( 0.38s) 0.13s ( 0.17s)
	71	Task 1 (worker) : 0.00s ( 0.55s) 0.00s ( 0.00s)
	72	Task 2 (bound) : 0.41s ( 0.41s) 0.13s ( 0.13s)
	73	Task 3 (worker) : 0.00s ( 0.55s) 0.00s ( 0.00s)
	74	}}}
	75
	76	Ask JaffaCake how the "tasks" relate to the "threads" for which we generate
	77	events. Perhaps in the existing GC evens add the info about which task
	78	does the job. BTW, is the time between event GCIdle and GCWork counted
	79	as GC time of the task?
	80
	81	{{{
	82	SPARKS: 300001 (17739 converted, 282262 overflowed, 0 dud, 0 GC'd, 0 fizzled)
	83	}}}
	84
	85	We have enough events for that (we calculate this using the SparkCounters
	86	events, but we could also use the precise per-spark events).