Awesome. This gives me some idea to try on my side 
Yup! I’ll update this thread on whether these settings pan out for us such that we try it in prod and if so, what does that look like. All depends on your workload, but that said, large carriers can hurt bad if you’re facing fragmentation problems, the probability of exhausting memory is greater because you have to create more carriers to satisfy an allocation request, and you just keep doing that song and dance until you’ve run out of memory. They should also be harder to nuke from orbit (i.e., you got many parts all sharing a few large carriers vs a few parts sharing lots of small carriers). The defaults are really good in this regard, but I think for us, smaller than the defaults is probably better, remains to be seen.
This case study is worth the read : Troubleshooting down the logplex rabbithole
Right, this has to do with linux (though from what I understand most operating systems these days use overcommit) and not with supercarrier. Though as documented and discussed in another thread, the linux overcommit strategy greatly effects how the supercarrier will behave. The default is 0 which is heuristic mode. If you’re not using supercarrier anymore, and don’t plan on it, then changing this is probably not worth it if everything is running fine in general for you now.
That said, here are docs on overcommit