Runtime: PrivateMemorySize64

[Jimmy062006]

Writing code in Dotcore 2.0 and trying to use Process.GetCurrentProcess().PrivateMemorySize64 on Linux will yield 0 as a result where by Windows OS's return the expected results.

Is this intended ?

[TAGC]

This issue can be reproduced in microsoft/dotnet:2.0-sdk:

// Program.cs

using System;
using System.Diagnostics;

namespace experiment
{
    class Program
    {
        static void Main()
        {
            var memorySize = Process.GetCurrentProcess().PrivateMemorySize64;
            Console.WriteLine($"Private memory: {memorySize}");
        }
    }
}

# Dockerfile

FROM microsoft/dotnet:2.0-sdk
WORKDIR /app
COPY . .
ENTRYPOINT dotnet run

Output

$ docker build . -q -t temp && docker run --rm temp
sha256:c3891ad59b7adf4db4dfb3d41b68fe015bfeab4a031740ad8692d343db7e492e
Private memory: 0

[ghost]

https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.Process/src/System/Diagnostics/Process.cs#L484 - Process class, check the PrivateMemorySize64 property

https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.Process/src/System/Diagnostics/ProcessManager.Linux.cs#L110 Is linux implementation of ProcessManager aka what create the ProcessInfo and it's supposed to assign private memory value to it, but there's a problem. The comment reads:

// We don't currently fill in the other values.
// A few of these could probably be filled in from getrusage,
// but only for the current process or its children, not for
// arbitrary other processes.

https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.Process/src/System/Diagnostics/ProcessInfo.cs If you want to see what ProcessInfo prototype is.

https://github.com/dotnet/corefx/blob/master/src/Common/src/Interop/Linux/procfs/Interop.ProcFsStat.cs is how they get those information.

[danmosemsft]

It seems to me the code could be improved to do as it says, at least fill it in for the current process. @Jimmy062006 was that what you needed it for?

[ghost]

Think this should be have at least a similar implementation on how Mono Runtime does it? It's basically reading from "/proc/{pid}/status" file.

[danmosemsft]

@stephentoub may be able to remember why he didn't do that.

[stephentoub]

It's basically reading from "/proc/{pid}/status" file.

This code reads from procfs. Which value maps to what's needed here?

[ghost]

According to Mono Runtime, it seems "VmData" is mapped to PrivateMemorySize64 as shown here: https://github.com/mono/mono/blob/master/mono/utils/mono-proclib.c#L633

[stephentoub]

Does VmData actually represent the same value as all non-shared memory?

[ghost]

http://ewx.livejournal.com/579283.html - VmData is calculated as the total address space usage (i.e. VmSize) with shared and stack pages subtracted.

And according to Proc.txt in Linux Repo in Github, it is mentioned that it is a private data segment:
https://github.com/torvalds/linux/blob/master/Documentation/filesystems/proc.txt#L248

[stephentoub]

with shared and stack pages subtracted.

Is it the right value then if stack is excluded? Is stack not included in PrivateMemorySize on Windows?

[stephentoub]

(Regardless, if the right values are available, it'd make sense to use that data to better populate the info object... though I think I'd want to see statm parsed rather than status.)

[ghost]

From what I gathered, stack is excluded from this calculation for VmData. I'm not sure on the other question.

[JustArchi]

If we need stack size we can very easily add value of VmStk from the same /proc/{pid}/status data to total VmData in order to get VmData + stack size. Not like it'll make the value that much different anyway, but if Windows does that, then we can do it too.

[Jimmy062006]

@danmosemsft I wanted to use it on a status command in the app I'm writing.

I then found out it worked fine in Windows but not Linux. So yes :)

[danmosemsft]

Does anyone on this thread want to take a shot at implementation? If so I will assign you the issue!

[Jimmy062006]

I decided to look at the /proc/pid/status file of one of my dotnet process's and now am a little confused by the numbers

/proc/16301/status
VmPeak:  3070764 kB
VmSize:  3067248 kB
VmLck:         4 kB
VmPin:         0 kB
VmHWM:     78796 kB
VmRSS:     72252 kB
RssAnon:           39556 kB
RssFile:           27860 kB
RssShmem:           4836 kB
VmData:  2874744 kB
VmStk:       132 kB
VmExe:       100 kB
VmLib:     70012 kB
VmPTE:       592 kB
VmSwap:        0 kB

Yet smem shows something different.

SMEM
PID User     Command                         Swap      USS      PSS      RSS
16301 opux     /home/opux/dotnet/dotnet Op        0    44520    50352    72144

[wtgodbe]

@danmosemsft @Jimmy062006 any update on this?

[Kein]

Welp, this is still an issue in 2.1 - any ideas what the milestone is aim for this?

[danmosemsft]

@kein as far as I can tell from this issue, nobody is working on it, and it's not scheduled. You're welcome to offer a PR if there's a bug here.

[tannergooding]

@danmosemsft, should this be marked up for grabs?

[danmosemsft]

Sure

[karelz]

Fixed in 3.1 in PR dotnet/corefx#42370 and in 5.0 (master) in PR dotnet/corefx#41122

[rharpavat]

Is there any plan to bring this fix to OSX as well? I'm currently using the WorkingSet64 property but that overestimates the amount of memory consumed.