8000 Add memory.kernelTCP support for linux by yongtang · Pull Request #37043 · moby/moby · GitHub
[go: up one dir, main page]

Skip to content

Conversation

yongtang
Copy link
Member

- What I did
This fix tries to address the issue raised in #37038 where
there were no memory.kernelTCP support for linux.

- How I did it

This fix add MemoryKernelTCP to HostConfig, and pass
the config to runtime-spec.

- How to verify it

Additional test case has been added.

- Description for the changelog

This fix fixes #37038.

Signed-off-by: Yong Tang yong.tang.github@outlook.com

@AkihiroSuda
Copy link
Member

This requires bumping up API version?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

KernelMemoryTCP

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DaemonInfo.KernelMemoryTCPLimit?

@yongtang
Copy link
Member Author

@AkihiroSuda Updated. Please take a look.

Copy link
Member
@AkihiroSuda AkihiroSuda left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yongtang yongtang force-pushed the 37038-kernelTCP branch 3 times, most recently from 15d1a14 to 66b32fe Compare May 13, 2018 14:34
@codecov
Copy link
codecov bot commented May 13, 2018

Codecov Report

❗ No coverage uploaded for pull request base (master@ea3ac62). Click here to learn what that means.
The diff coverage is 28.57%.

@@            Coverage Diff            @@
##             master   #37043   +/-   ##
=========================================
  Coverage          ?   36.13%           
=========================================
  Files             ?      610           
  Lines             ?    45219           
  Branches          ?        0           
=========================================
  Hits              ?    16340           
  Misses            ?    26642           
  Partials          ?     2237

@yongtang
Copy link
Member Author

@AkihiroSuda The PR has been updated. Please take a look.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

!= 0 as in KernelMemory?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AkihiroSuda The PR has been updated. Please take a look.

Copy link
Member
@vdemeester vdemeester left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Design and Code LGTM 👼

Copy link
Member
@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

left some nits; generally this looks good to me.

I'm curious (n00b warning ahead):

  • how does this relate to general "memory" limits for the container? I take it this is outside of that limit? (i.e., a container with a memory limit can still exhaust the host by consuming memory for TCP)?
  • Would there be some "formula" we can apply so that there's an easy way to set all memory constraints in one go (in addition to per type) - similar to how we added the --cpus option for services?
  • I assume we want to add this option for services as well?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

" (in bytes)" ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ping @yongtang

api/swagger.yaml Outdated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

" in bytes" ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we anticipate adding this to docker container update as well, we need to think how to reset this

@kolyshkin
Copy link
Contributor
kolyshkin commented May 17, 2018

I guess we should add a sanity check that memory.kernelTCP < memory.kernel in case user specifies both. I have yet to check but assume that memory.kernel also limits the tcp memory.

Update: I was wrong, it's a separate limit, not accounted into kmem

@thaJeztah
Copy link
Member

Discussing in the maintainers meeting; how this relates to sysctl memory limits for TCP; @kolyshkin mentions those are per network namespace and the configuration in this PR is per cgroup (we should look into that; also what happens if two containers join the same networking namespace and have different settings).

@kolyshkin will also look into the questions I put above (unless @yongtang has the answers 😄)

@AkihiroSuda
Copy link
Member

could you rebase?

This fix tries to address the issue raised in 37038 where
there were no memory.kernelTCP support for linux.

This fix add MemoryKernelTCP to HostConfig, and pass
the config to runtime-spec.

Additional test case has been added.

This fix fixes 37038.

Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
@yongtang
Copy link
Member Author

@thaJeztah @AkihiroSuda The PR has been rebased. Please take a look and see if it is ready?

Copy link
Member
@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@vdemeester
Copy link
Member

@yongtang some CI issues

05:57:22 The swagger spec at "api/swagger.yaml" is valid against swagger specification 2.0
05:57:24 The result of hack/generate-swagger-api.sh differs
05:57:24 
05:57:24 diff --git a/api/types/container/container_wait.go b/api/types/container/container_wait.go
05:57:24 index 9e3910a6b4..06b0f02077 100644
05:
6284
57:24 --- a/api/types/container/container_wait.go
05:57:24 +++ b/api/types/container/container_wait.go
05:57:24 @@ -7,14 +7,6 @@ package container
05:57:24  // See hack/generate-swagger-api.sh
05:57:24  // ----------------------------------------------------------------------------
05:57:24  
05:57:24 -// ContainerWaitOKBodyError container waiting error, if any
05:57:24 -// swagger:model ContainerWaitOKBodyError
05:57:24 -type ContainerWaitOKBodyError struct {
05:57:24 -
05:57:24 -	// Details of an error
05:57:24 -	Message string `json:"Message,omitempty"`
05:57:24 -}
05:57:24 -
05:57:24  // ContainerWaitOKBody OK response to ContainerWait operation
05:57:24  // swagger:model ContainerWaitOKBody
05:57:24  type ContainerWaitOKBody struct {
05:57:24 @@ -27,3 +19,11 @@ type ContainerWaitOKBody struct {
05:57:24  	// Required: true
05:57:24  	StatusCode int64 `json:"StatusCode"`
05:57:24  }
05:57:24 +
05:57:24 +// ContainerWaitOKBodyError container waiting error, if any
05:57:24 +// swagger:model ContainerWaitOKBodyError
05:57:24 +type ContainerWaitOKBodyError struct {
05:57:24 +
05:57:24 +	// Details of an error
05:57:24 +	Message string `json:"Message,omitempty"`
05:57:24 +}
05:57:24 
05:57:24 Please update api/swagger.yaml with any api changes, then 
05:57:24 run `hack/generate-swagger-api.sh`.

@thaJeztah
Copy link
Member

The swagger failure is due to swagger-gen using a map, therefore randomizing the order 😞 (that's being addressed by #36714, but it stalled, so will have to be carried)

@vdemeester
Copy link
Member

@thaJeztah oohhh 😱 🙀 😅

@thaJeztah
Copy link
Member

Failure is now due to a known flaky test #32673

17:28:43 FAIL: docker_api_swarm_test.go:296: DockerSwarmSuite.TestAPISwarmLeaderElection
17:28:43 
17:28:43 [d4d1c0cfecaee] waiting for daemon to start
17:28:43 [d4d1c0cfecaee] daemon started
17:28:43 
17:28:43 [d17b61e9c4c74] waiting for daemon to start
17:28:43 [d17b61e9c4c74] daemon started
17:28:43 
17:28:43 [db8e51e0badfc] waiting for daemon to start
17:28:43 [db8e51e0badfc] daemon started
17:28:43 
17:28:43 [d4d1c0cfecaee] exiting daemon
17:28:43 Waiting for election to occur...
17:28:43 assertion failed: error is not nil: Error response from daemon: rpc error: code = DeadlineExceeded desc = context deadline exceeded: [d17b61e9c4c74] (*Daemon).GetNode: NodeInspectWithRaw("1dq8drt7zguegiv3g88597n9y") failed
17:28:43 waited for 20.001376311s (out of 30s)
17:28:43 [d17b61e9c4c74] exiting daemon
17:28:43 [db8e51e0badfc] exiting daemon

everything else passed, so I'll merge

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Expose API for setting runtimeSpec.linux.resources.memory.kernelTCP
6 participants
0