the kernal parameter vm.max_map_count in /etc/sysctl.conf is don't work!

[vagile-cn]

when I set vm.max_map_count in /etc/sysctl.conf and reload the parameter with sysctl -p,
I'll get an error:
sysctl: cannot stat /proc/sys/vm/max_map_count: No such file or directory
and the parameter dosn't work.

[vagile-cn]

@DarthSpock thank you for answer my question
but I mean I can't make WSL kernal parameter work

[vagile-cn]

@DarthSpock all right
There are still a lot of imperfections in WSL = =!

[fpqc]

um, sysctl is not the same as systemctl. Systemctl is the command and control application for the Systemd daemon. sysctl.conf is a configuration file that gets loaded on startup that sets certain kernel parameters.

The problem is that in the version you're using, /proc/sys/vm/max_map_count is not yet supported in the WSL procfs. I think it might be supported in more recent versions, but I don't remember.

given a particular kernel parameter (kernel.param.name in this example) in sysctl.conf with a value value, in general, what running sysctl -p does is the same as doing

echo "value" > /proc/sys/kernel/param/name

[WSLUser]

I was thinking that sysctl might rely on systemctl or at least systemd. If I'm mistaken, then I learned something new.

[fpqc]

Yes you are mistaken. Sysctl is also in freebsd (though freebsd doesn't have a virtual filesystem for its kernel params, so it uses a special sysctl syscall).

max_map_count is not available right now in sysfs. The only params in /proc/sys/vm are min_free_kbytes, overcommit_memory, and swappiness.

[vagile-cn]

@fpqc
thank u for understanding what I mean.
I just try echo 65530>>/proc/sys/vm/max_map_count
but I get an error as same as use "sysctl -p" to reload kernel parameter

-bash: /proc/sys/vm/max_map_count: Operation not permitted

[vagile-cn]

@fpqc
I am thinking about a question.
Is this parameter necessary?
I think the limit of max virtual memory may be in Windows.
is this the reason why can't use the parameter in WSL(Ubuntu).

[fpqc]

@vagile-cn That particular parameter of the linux memory manager is not available right now in the WSL driver surface. If you need it for something specific, that will help the developers prioritize it. If you don't have any particular reason to use it, then don't.

[vagile-cn]

@fpqc I just run elasticsearch in WSL = =!

[Dakkaron]

I can second that. Running ElasticSearch in WSL causes the paged pool of the memory to bloat insanely (my system stops working properly after it bloats to more than 14GB of my 16GB RAM). It stays bloated even if I close every WSL window. The only thing that helps is a reboot or to clear the working set memory using RAMMap. Similar things happen when running Django in debug mode in WSL.

This bloating process usually takes about 6 to 12 hours to fill up my RAM.

[fpqc]

Could you make that memory problem its own issue? That sounds like a bug while this is a feature request

[vagile-cn]

@fpqc sure~ I'd like create a new issue when I have time.

[therealkenc]

WSL causes the paged pool of the memory to bloat insanely

Norton?

[Dakkaron]

@therealkenc Nope, I don't run any antivirus except Windows Defender.

[rofrol]

@vagile-cn

try as root

$ sudo passwd root
$ su -
$ echo 65530 >> /proc/sys/vm/max_map_count

[Dakkaron]

@rofrol
This is the basic problem this issue is about: it cannot be created or set, no matter what user is used (yes, root cannot do it either).

[shoffmeister]

WSL does not use a Linux kernel, is not a Linux kernel. Trying to apply Linux kernel parameters to WSL therefore is almost never going to work out as you intend.

The advice from above

Could you make that memory problem its own issue? That sounds like a bug while this is a feature request

is the only thing that will help you. By creating such a report, you enable the WSL developers to investigate the memory ballooning behaviour and introduce changes into WSL (fix/config etc) to address that behaviour.

It is almost certain, that those Linux kernel /sys settings you are looking for will never pop up on WSL. WSL is intended to run GNU/Linux user-mode applications natively (much in the spirit of the user-mode Linux of many years ago). WSL is not a virtual machine host which emulates hardware, on top of which the Linux kernel runs, on top of which the GNU/Linux user-mode applications run.

[rofrol]

@Dakkaron I'm not telling you some basic instruction, but what I actually did and it worked in the sense that:

$ cat /proc/sys/vm/max_map_count
65530

but I couldn't preserve after reboot.

[shoffmeister]

Did setting the max_map_count parameter have any effect on the virtual memory manager that is employed by WSL?

[rofrol]

@Dakkaron sorry, you are right. I can't set it:

# echo 65530 >> /proc/sys/vm/max_map_count
-su: /proc/sys/vm/max_map_count: Operation not permitted

[shoffmeister]

@rofrol, @Dakkaron - there is no such parameter, because there is no Linux kernel. There is a (Windows-layered) "kernel" which implements quite a few syscalls that the Linux kernel exposes. But, still, there is no Linux kernel. Because there is no Linux kernel, the "tweak this Linux kernel setting" instructions you will find all over the Internet will almost never apply.

The only means to make progress for this issue here is that an interested party opens up a separate ticket, describing the memory ballooning behaviour in detail, and the best / fastest way to reproduce it. WSL developers can then review whether some action can be taken.

[therealkenc]

there is no such parameter, because there is no Linux kernel ... the "tweak this Linux kernel setting" instructions you will find all over the Internet will almost never apply

That isn't strictly speaking true. Certain kernel parameters might be emulated. A few already are. Whether map_map_count will be one that is emulated I can't tell you, but the semantics of the tunable parameter is independent of the implementation of the tunable. But to your more salient point...

an interested party opens up a separate ticket, describing the memory ballooning behaviour in detail

Right. The OP skidded off the track from the gate for lack of use case or context (which I gather is ElasticSearch). ElasticSearch I in turn gather has special memory management requirements. If an interested party exists, please reboot this one following CONTRIBUTING.md.

[shoffmeister]

@therealkenc . please note the very, very careful, very considerate, and very deliberate use of the word "almost" :)

From my point of view, educating users that WSL is not the Linux kernel, but the Windows kernel (whatever that translates to these days in the architectural world) might help in directing these outlier cases into the right direction.

From the more recent issues that I have seen opened on WSL, it would seem as if users think that WSL is the Linux kernel, with all userland (runlevels, init system, and whatever-not) on top of it.

It is not, at this time, and (economically speaking) will never be 100%.

That is neither bad in itself, nor good in itself itself. It just means that WSL != any-one-whatever-Linux-kernel-version. And people don't see that, don't get that. And up goes the cost of support and down goes the level of user satisfaction. This, I think, is a pity.

(Disclaimer: I went the "let's get those Windows things running on Linux" way about two decades ago. Ah, and "on FreeBSD, NetBSD, Solaris" ....)

[therealkenc]

Ran course. Someone motivated could open a well-formed issue following CONTRIBUTING.md along the lines of #1809. "much /proc/sys/vm/* missing" or somesuch. If there is a memory ballooning issue with ElasticSearch (or anything else), ditto.

[Dakkaron]

Would it be possible to create that file as read-only with a fitting value in it? I keep getting errors with programs that expect that value to exist, e.g. Elastic Search. I don't care too much about what that value is, but scripts keep crashing because that file does not exist. Maybe just make that file writable but ignored or something.

Other files in this folder seem to exist and (maybe) do something, e.g. min_free_kbytes, overcommit_memory and swappiness.

[therealkenc]