Andrew McCreight [:mccr8] Reporter
	Description • 11 years ago

1mb is a lot for B2G, so it would be nice if this could be changed at compile time to, say, 250kb.

	Andrew McCreight [:mccr8] Reporter
	Comment 1 • 11 years ago

In bug 941837, billm points out a previous bug that attempted to reduce chunk size to 64k, bug 671702.

	Nicholas Nethercote [inactive]
	Comment 2 • 11 years ago

> In bug 941837, billm points out a previous bug that attempted to reduce
> chunk size to 64k, bug 671702.

The results there were very mixed, but it might be worth trying again with B2G-specific workloads.

	Jon Coppeard (:jonco) (PTO until 14th September) Assignee
	Comment 3 • 10 years ago

Here's a patch to test changing the chunk size to 256K.

Do we want this to be a configure option or will it be sufficient to have ifdefs for B2G do you think?

Also I'm unsure as to how to measure the impact of this for B2G.

	Terrence Cole [:terrence]
	Comment 4 • 10 years ago

I think as a first pass it would be fine to just do #ifdef B2G. Why do we need to move all of our declarations into the API? I think we should be able to make the appropriate changes internally in Heap.h and just have an #ifdef B2G block in HeapAPI.h with the different numbers.

	Jon Coppeard (:jonco) (PTO until 14th September) Assignee
	Comment 5 • 10 years ago

For some reason I couldn't get this to work with #ifdef MOZ_B2G.  I don't understand how all the configure stuff works, but it seems this isn't propagated when building the engine, at least not for desktop B2G builds.

	Terrence Cole [:terrence]
	Comment 6 • 10 years ago

Comment on attachment 8454547 [details] [diff] [review]
reduce-chunk-size-for-b2g

Review of attachment 8454547 [details] [diff] [review]:
-----------------------------------------------------------------

Great! That's more like what I was thinking.

	Terrence Cole [:terrence]
	Comment 7 • 10 years ago

Nicolas, what would be the best way to figure out the impact of this change on B2G?

	Carsten Book [:Tomcat]
	Comment 8 • 10 years ago

sorry had to backout this change for test failures like https://tbpl.mozilla.org/php/getParsedLog.php?id=43733909&tree=Mozilla-Inbound

	Jon Coppeard (:jonco) (PTO until 14th September) Assignee
	Comment 9 • 10 years ago

Sorry, it seems I uploaded the wrong version of the patch for review.  Comment 5 should make more sense now.

	Terrence Cole [:terrence]
	Comment 10 • 10 years ago

Comment on attachment 8455235 [details] [diff] [review]
reduce-chunk-size-for-b2g v2

Review of attachment 8455235 [details] [diff] [review]:
-----------------------------------------------------------------

Okay, makes sense.

	Jon Coppeard (:jonco) (PTO until 14th September) Assignee
	Comment 11 • 10 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/21f83c1eba92

	Nicolas B. Pierron [:nbp]
	Comment 12 • 10 years ago

(In reply to Terrence Cole [:terrence] from comment #7)
> Nicolas, what would be the best way to figure out the impact of this change
> on B2G?

Octane does not run anymore on Unagis, but I have 2 flame which are constantly running.  One has 1 GB and the other runs with 512 mb of RAM.  AreWeFastYet [1] should report how these patches change the behaviour on benchmarks.

For the memory aspect of the question, at the moment you can have a look at datazilla (select one of the *_memory tests on the bottom left box) to see what is the start-up memory of one application [2].  Note that the concern is on Gecko master, and not inbound, so only expect to see the variations after the merge.

[1] http://arewefastyet.com/?a=b&view=regress#machine=26 (due to an adb issue, I was unable to report anything before this morning)
[2] https://datazilla.mozilla.org/b2g/?branch=master&device=flame&range=7&test=settings_memory&app_list=browser,calendar,camera,clock,contacts,email%20FTU,fm_radio,gallery,marketplace,messages,music,phone,rss,settings,system_rss,system_uss,system_vsize,template,usage,uss,video,vsize&app=clock&gaia_rev=40cac290f0a3253d&gecko_rev=c11ea2f54a6a&plot=avg

	Terrence Cole [:terrence]
	Comment 13 • 10 years ago

Great! That's extremely helpful!

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)
	Comment 14 • 10 years ago

https://hg.mozilla.org/mozilla-central/rev/21f83c1eba92

	Terrence Cole [:terrence]
	Comment 15 • 10 years ago

This appears to have resulted in a sharp drop to system rss, uss, and pss of about 50MiB. Full of win!

	Terrence Cole [:terrence]
	Comment 16 • 10 years ago

Note: I'm assuming for now that the scale bars are actually in MiB, not KiB, because a VmSize of 400KiB is flat-out impossible.