What is the 'proportional' in the about:memory?

[CqN]

Does proportional means shared memory?

Cordially, CqN

[Adam Langley]

On Thu, Feb 3, 2011 at 3:55 PM, CqN <chacko...@gmail.com> wrote:
> Does proportional means shared memory?

It's a Linux term. See http://lwn.net/Articles/230975/

AGL

[CqN]

Adam, Thank you!

For the cr-48, why are the PSS showing N/A for most of the items?

In the curret (dev channel release) implementation, the USS as
described there, released when a tab is deleted? Of course I do not
know what the USS for each is, but I do not see any effect here when I
delete a tab, until after a power down / reboot.

Cordially, CqN?

On Feb 3, 12:56 pm, Adam Langley <a...@chromium.org> wrote:

[Adam Langley]

On Thu, Feb 3, 2011 at 4:21 PM, CqN <chacko...@gmail.com> wrote:
> For the cr-48,  why are the PSS showing N/A for most of the items?

The method that we use for sandboxing sadly causes the kernel to hide
the PSS numbers for our renderers. (Although, on ChromeOS, we control
the kernel so we could fix that I suppose.)

> In the curret (dev channel release) implementation, the USS as
> described there, released when a tab is deleted?   Of course I do not
> know what the USS for each is, but I do not see any effect here when I
> delete a tab, until after a power down / reboot.

The private memory for a renderer should be released to the system
when you close the tabs for that renderer. (USS is private memory, but
'private' is the word we use on about:memory.)

AGL

[CqN]

Adam,

If I understand correctly, proportional (==PSS) should be >=
private. Correct? This appears to be the case here on my cr-48
display for the couple of processes which shows both metrics. But for
the first entry, chrome as a whole, it seems way off. Last look:
private 348K, proportional 70K. What gives?

Cordially, CqN


On Feb 3, 1:25 pm, Adam Langley <a...@chromium.org> wrote:

[Terry Lambert]

On Fri, Feb 4, 2011 at 4:12 PM, CqN <chacko...@gmail.com> wrote:

Adam,

If I understand correctly, proportional (==PSS)  should be >=
private.  Correct?

Nope. It depends on how many private pages something uses for data and code compared to how many it shares, usually via shared libraries or text for additional copies of the program.

If the only program on your system were "init", it would be all USS.  PSS is a proportional measure of the number of pages shared by more than one process.  By definition, it's always going to be "number of shared pages / N, N>= 2".

 

 This appears to be the case here on my cr-48
display for the couple of processes which shows both metrics.  But for
the first entry, chrome as a whole, it seems way off.  Last look:
private 348K, proportional 70K.  What gives?

How many Chromes are you running at once?  8-).

-- Terry

 

Cordially, CqN


On Feb 3, 1:25 pm, Adam Langley <a...@chromium.org> wrote:

> On Thu, Feb 3, 2011 at 4:21 PM, CqN <chackoner...@gmail.com> wrote:
> > For the cr-48,  why are the PSS showing N/A for most of the items?
>
> The method that we use for sandboxing sadly causes the kernel to hide
> the PSS numbers for our renderers. (Although, on ChromeOS, we control
> the kernel so we could fix that I suppose.)
>
> > In the curret (dev channel release) implementation, the USS as
> > described there, released when a tab is deleted?   Of course I do not
> > know what the USS for each is, but I do not see any effect here when I
> > delete a tab, until after a power down / reboot.
>
> The private memory for a renderer should be released to the system
> when you close the tabs for that renderer. (USS is private memory, but
> 'private' is the word we use on about:memory.)
>
> AGL

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
   http://groups.google.com/a/chromium.org/group/chromium-dev

[CqN]

Terry,

That is not how I read this, quoted from the above article:

The "proportional set size" (PSS) of a process is the count of pages
it has in memory, where each page is divided by the number of
processes sharing it. So if a process has 1000 pages all to itself,
and 1000 shared with one other process, its PSS will be 1500. The
unique set size (USS), instead, is a simple count of unshared pages.
It is, for all practical purposes, the number of pages which will be
returned to the system if the process is killed.

I think, in the your eqn, N=1 for the non shared pages.

BTW, I am on the google chrome netbook cr-48.

Cordially, CqN

On Feb 4, 6:48 pm, Terry Lambert <tlamb...@chromium.org> wrote:

> > Chromium Developers mailing list: chromium-...@chromium.org

[Peter Kasting]

FWIW, this probably belongs on the chromium-os-discuss group as it is both discussion (vs. development) and Chrome OS (vs. Chrome).

PK

[Adam Langley]

On Fri, Feb 4, 2011 at 7:12 PM, CqN <chacko...@gmail.com> wrote:
> the first entry, chrome as a whole, it seems way off.  Last look:
> private 348K, proportional 70K.  What gives?

I believe that private should always be less then, or equal to,
proportional memory for any processes. However, owing to the
previously mentioned sandbox issue that prevents proportional memory
amounts from being read, that may not be true for summations.

So I'm assuming that you're seeing private < proportional for a line
called "Chrome" or some such. That line is the sum of the private and
proportional values for the processes which are part of that instance.
However, where we don't know the proportional memory for a process, it
counts as zero.

AGL