Re: [RFC][PATCH 2/7] RSS controller core

[snip]

We need to decide whether we want to do per-container memory
limitation via these data structures, or whether we do it via
a physical scan of some software zone, possibly based on Mel's
patches.
why not do simple page accounting (as done currently
in Linux) and use that for the limits, without
keeping the reference from container to page?
As I've already answered in my previous letter simple
limiting w/o per-container reclamation and per-container
oom killer isn't a good memory management. It doesn't allow
to handle resource shortage gracefully.
per container OOM killer does not require any container
page reference, you know _what_ tasks belong to the
container, and you know their _badness_ from the normal
OOM calculations, so doing them for a container is really
straight forward without having any page 'tagging'
That's true. If you look at the patches you'll
find out that no code in oom killer uses page 'tag'.

so what do we keep the context -> page reference
then at all?

We need this for
1. keeping page's owner to uncharge to IT when page
goes away. Or do you propose to uncharge it to
current (i.e. ANY) container like you do all across
Vserver accounting which screws up accounting with
pages sharing?
2. managing LRU lists for good reclamation. See Balbir's
patches for details.
3. possible future uses - correct sharing accounting,
dirty pages accounting, etc

for the reclamation part, please elaborate how that will
differ in a (shared memory) guest from what the kernel
currently does ...
This is all described in the code and in the
discussions we had before.

must have missed some of them, please can you
point me to the relevant threads ...

lkml.org archives and google will help you :)

TIA,
Herbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [PATCH 1/2] rcfs core patch
    ... will be a 2.2 release soon, with all the patches ... ... Slabs allocated from interrupt context are charged to ... non-intrusive accounting is concerned. ... a guest, regardless of how many times it is shared ...
    (Linux-Kernel)
  • Re: [PATCH 1/2] rcfs core patch
    ... will be a 2.2 release soon, with all the patches ... ... Slabs allocated from interrupt context are charged to ... non-intrusive accounting is concerned. ... So non-intrusiveness is a very weird argument from you. ...
    (Linux-Kernel)
  • Re: [PATCH] BC: resource beancounters (v2)
    ... UBC virtual memory management refuses occur on mmap's. ... if mappings are private then yes, you can not mmap too much. ... The task of limiting a container to 4.5GB of memory bottles down to the ... My idea only is that any of them would need accounting anyway ...
    (Linux-Kernel)
  • Re: [RFC][PATCH 1/7] Resource counters
    ... Each resource accounting container is supposed to ... Is there any way to indicate that there are no limits on this container. ... return ret; ...
    (Linux-Kernel)
  • [RFC][PATCH 0/8] RSS controller for containers
    ... Here is set of patches that implements a *simple minded* RSS controller ... Build the kernel and mount the container filesystem ...
    (Linux-Kernel)