runtime: default to MADV_DONTNEED on Linux backport to golang 1.15 subrelease

[rakeshlacework]

What version of Go are you using (go version)?

$ go version
go version go1.15.6 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/rakesh/.cache/go-build"
GOENV="/home/rakesh/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/rakesh/works/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/rakesh/works"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go-1.15.6"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go-1.15.6/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/rakesh/works/src/github.com/amicontained/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build232963154=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Is there a thought to back port this change into golang 1.15 subrelease to expedite availability of this change?

What did you expect to see?

What did you see instead?

[ALTree]

From Minor Releases:

Our default decision should always be to not backport, but fixes for security issues, serious problems with no workaround, and documentation fixes are backported to the most recent two release branches, if applicable to that branch.

I don't believe the MADFREE issue qualifyes as a "serious problem with not workaround" (you can always set GODEBUG=madvdontneed=1), so it's unlikely to be backported.

[rakeshlacework]

From Minor Releases:

Our default decision should always be to not backport, but fixes for security issues, serious problems with no workaround, and documentation fixes are backported to the most recent two release branches, if applicable to that branch.

I don't believe the MADFREE issue qualifyes as a "serious problem with not workaround" (you can always set GODEBUG=madvdontneed=1), so it's unlikely to be backported.

@ALTree thanks for highlighting that while I agree with the "workaround" part but I find that if memory consumption of a golang applications changes 2x-3x just because one chooses to change the toolchain does put us in the middle of "serious problem".

Looking at the 1.16 release timeline of 1st Feb (with 75% done) I wonder if you could share some insights into the release date?

[ianlancetaylor]

Time will tell, but I think we're on track for a 1.16 release in early February.