/cc @thockin this aligns with our IRC discussion.

/cc @danmcp per our chat as well.

Hi all,
For this issue, so we want to support memory swap at both kubelet and API level?

1. Add option --container-memory-swap-limit-factor=0 to kubelet, and it'll be a global default settings for memory swap
2. In the container's resource limits, we can also specify something like container.resources.limits.memoryswap=1, then it'll use 1L as memory swap(L is the memory specified). And it'll map to 2L of docker memory swap, as this value in docker is the summary of memory and memory swap.

We're also customizing k8s to support memory swap in our project, so it can leverage docker memory swap. I'd like to contribute code using this issue, is my understanding above correct?
Let me know if any design change, thanks!

I'd rather not put factors into a ResourceList, as is implied in item 2 of previous comment. All the items in resources.limits should be additive. If you want to allow users to specify this from the API, then they can just specify an absolute amount of swap, or if they leave it empty, then some admission controller could default it, and they could set it to an explicit value of 0 or maybe 1 if they don't want any swap.

Hi erictune,
I agree with you on option 2, we'd better to let the user specify an absolute value for memory swap instead of factors in API approach, it'll make it consistent with Docker, and sure we should have default value if the user doesn't use it. How about the question below, the memory swap here should be only memory swap or the summary?

And it'll map to 2L of docker memory swap, as this value in docker is the summary of memory and memory swap.

How about kubelet level support, do we still need it?
Thanks.

The default value should be to not use swap at all.

I think docker chose their format to be just like the cgroups interface. But, I don't think we need to copy that pattern. I'd rather that the resources list does not double-count resources or mix resources. It should be easy to add up resource lists like you add up vectors, to get aggregate amounts of resources.

So, I think swap should just be the amount of swap, not swap + memory. And it should be called "swap" not "memoryswap", to reflect that.

One case to think about: Swapfiles can be on rotating disk or on SSD. This gives very different performance characteristics. Also, the scheduler needs to subtract any swap space from the storage space of the node when a pod is bound to it. It needs to know whether to subtract that from rotating disk or SSD. Should, should we have separate "diskswap" and "ssdswap" resources?

Hi erictune,
that's a good point, but I'm not sure why we need separate resource for "diskswap" and "ssdswap", the user can use normal disk or SSD memory swap as they need from performance perspective, but we only need to substract the size of swap when calculate the space size of a node.
Do you mean the swap size maybe differenent depending on it's normal disk or SSD?
Thanks for help!

I was thinking of the case where swap files are added dynamically by
kubelet in response to pods being started. In this model, the scheduler
needs to subtract the swap from the resources of the machine, and it needs
to know which resources to reduce..

However, if nodes are statically provisioned with swap, and they exclude
the provisioned swap resources from the reported capacity, then I agree we
can do it like you say.

On Sun, Jun 28, 2015 at 11:20 PM, WangLei notifications@github.com wrote:

Hi erictune,
that's a good point, but I'm not sure why we need separate resource for
"diskswap" and "ssdswap", the user can use normal disk or SSD memory swap
as they need from performance perspective, but we only need to substract
the size of swap when calculate the space size of a node.
Do you mean the swap size maybe differenent depending on it's normal disk
or SSD?
Thanks for help!

—
Reply to this email directly or view it on GitHub
#7294 (comment)
.

Hi erictune,
OK, I see, then we may also want to use 'memory swap' as a factor when the scheduler tries to calculate the fit node and schedule the pod, and we also need to know the total size of swap on each node someway.
Do we already have the swap size or capability added in current scheduler and kubelet implementation? it'll probably need more change if we want to add them all, thanks!