We've been talking about this; Jim is actively researching. tcmalloc doesn't fully release yet, but it will. This is second priority to getting the decommit strategy correct.
Mike On Thu, Oct 1, 2009 at 11:24 AM, Marc-Antoine Ruel <[email protected]>wrote: > > On Thu, Oct 1, 2009 at 2:22 PM, Anton Muhin <[email protected]> wrote: > > > > On Thu, Oct 1, 2009 at 10:18 PM, cpu <[email protected]> wrote: > >> > >> Did somebody answer Marc-Antoine question? > >> > >> I don't see us ever releasing pages. I can fathom that we are not > >> doing that so I must be reading the code wrong. > > > > What to you mean by release? decommitting or releasing reserved pages? > > > > If releasing reserved pages, we don't do that, but I never saw > > problems with it and if page is only reserved, it has no performance > > implications---page is not swapped out/in. > > > > yours, > > anton. > > AFAIK, VAS fragmentation is an issue in the browser. This shouldn't be > overlooked. > > M-A > > >> On Oct 1, 10:11 am, Erik Kay <[email protected]> wrote: > >>> On Thu, Oct 1, 2009 at 8:49 AM, Mike Belshe <[email protected]> > wrote: > >>> > see about:tcmalloc (credit to sgk) - which dumps the *browser* stats. > We > >>> > need to plumb other processes. > >>> > >>> This is really cool. My question of cost to compute was whether it > >>> makes sense to get this into end-user histograms, or if we can measure > >>> this periodically over a page cycler run. > >>> > >>> As you say, getting it into the other processes seems like the higher > priority. > >>> > >>> Erik > >>> > >>> > >>> > >>> > Mike > >>> > >>> > On Thu, Oct 1, 2009 at 8:42 AM, Erik Kay <[email protected]> > wrote: > >>> > >>> >> On Wed, Sep 30, 2009 at 11:22 AM, James Robinson <[email protected] > > > >>> >> wrote: > >>> > >>> >> > I agree completely that this seems to be an issue Here's what > >>> >> > about:tcmalloc > >>> >> > says about my browser process right now (which is at around 267MB > >>> >> > according > >>> >> > to the app's Task Manager): > >>> > >>> >> > MALLOC: 207097856 ( 197.5 MB) Heap size > >>> >> > MALLOC: 12494760 ( 11.9 MB) Bytes in use by application > >>> >> > MALLOC: 188563456 ( 179.8 MB) Bytes free in page heap > >>> > >>> >> This is pretty eye-popping data. > >>> > >>> >> How expensive is it to compute this data? Is it something we can > >>> >> report back in histograms? Is it something we can add to some of > our > >>> >> page cycler tests as perf data so we can track improvements and > >>> >> regressions? > >>> > >>> >> Erik > >> > > >> > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
