Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
rakeshlacework opened this issue Jan 4, 2021 · 3 comments
Closed

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

rakeshlacework opened this issue Jan 4, 2021 · 3 comments
Labels
FrozenDueToAge

Comments

@rakeshlacework
Copy link

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
Copy link
Member

ALTree commented Jan 4, 2021

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 ALTree closed this as completed Jan 4, 2021
@rakeshlacework
Copy link
Author

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
Copy link
Contributor

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

@golang golang locked and limited conversation to collaborators Jan 4, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@ianlancetaylor @ALTree @gopherbot @rakeshlacework