* Re: [lxc-devel] Memory Resources [not found] ` <ac1c4bf20908230513q383fb338ne02e8f19f6ef18a6-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2009-08-23 16:18 ` Daniel Lezcano [not found] ` <4A916BC9.8040905-GANU6spQydw@public.gmane.org> 0 siblings, 1 reply; 43+ messages in thread From: Daniel Lezcano @ 2009-08-23 16:18 UTC (permalink / raw) To: kt-S89nZTSLPHGGdvJs77BJ7Q Cc: Linux Containers, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Krzysztof Taraszka wrote: > Hello, > > I am running lxc on my debian unstable sandbox and I have a few question > about memory managament inside linux containers based on lxc project. > > I have got linux kernel 2.6.30.5 with enabled : > > +Resource counter > ++ Memory Resource Controller for Control Groups > +++ Memory Resource Controller Swap Extension(EXPERIMENTAL) > > lxc-checkconfig pass all checks. > > I read about cgroups memory managament (Documentation/cgroups/memory.txt) > and I tried to pass those value to my debian sandbox. > > And... > 'free -m' and 'top/htop' still show all available memory inside container > (also If I set 32M for lxc.cgroup.memory.limit_in_bytes and > lxc.cgroup.memory.usage_in_bytes; and 64M for > lxc.cgroup.memory.memsw.usage_in_bytes and > lxc.cgroup.memory.memsw.limit_in_bytes free and top show all resources). > > What I did wrong? Does the container always show all available memory > resources without cgroup limitations? At the first glance I would say the configuration is correct. But AFAIR, the memory cgroup is not isolated, if you specify 32MB you will see all the memory available on the system either if you are not allowed to use more than 32MB. If you create a program which allocates 64MB within a container configured with 32MB, and you "touch" the pages (may be that can be done with one mmap call with the MAP_POPULATE option), you should see the application swapping and the "memory.failcnt" increasing. IMHO, showing all the memory available for the system instead of showing the allowed memory with the cgroup is weird but maybe there is a good reason to do that. -- Daniel ps: cc'ed the containers@ ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <4A916BC9.8040905-GANU6spQydw@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <4A916BC9.8040905-GANU6spQydw@public.gmane.org> @ 2009-08-23 16:59 ` Krzysztof Taraszka [not found] ` <ac1c4bf20908230959j4cda58cel3bcf4f3822d50bb1-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 43+ messages in thread From: Krzysztof Taraszka @ 2009-08-23 16:59 UTC (permalink / raw) To: lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Linux Containers 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> > Krzysztof Taraszka wrote: > >> Hello, >> >> I am running lxc on my debian unstable sandbox and I have a few question >> about memory managament inside linux containers based on lxc project. >> >> I have got linux kernel 2.6.30.5 with enabled : >> >> +Resource counter >> ++ Memory Resource Controller for Control Groups >> +++ Memory Resource Controller Swap Extension(EXPERIMENTAL) >> >> lxc-checkconfig pass all checks. >> >> I read about cgroups memory managament (Documentation/cgroups/memory.txt) >> and I tried to pass those value to my debian sandbox. >> >> And... >> 'free -m' and 'top/htop' still show all available memory inside container >> (also If I set 32M for lxc.cgroup.memory.limit_in_bytes and >> lxc.cgroup.memory.usage_in_bytes; and 64M for >> lxc.cgroup.memory.memsw.usage_in_bytes and >> lxc.cgroup.memory.memsw.limit_in_bytes free and top show all resources). >> >> What I did wrong? Does the container always show all available memory >> resources without cgroup limitations? >> > > At the first glance I would say the configuration is correct. > But AFAIR, the memory cgroup is not isolated, if you specify 32MB you will > see all the memory available on the system either if you are not allowed to > use more than 32MB. If you create a program which allocates 64MB within a > container configured with 32MB, and you "touch" the pages (may be that can > be done with one mmap call with the MAP_POPULATE option), you should see the > application swapping and the "memory.failcnt" increasing. > > IMHO, showing all the memory available for the system instead of showing > the allowed memory with the cgroup is weird but maybe there is a good reason > to do that. > > Thank you Daniel for your reply. I think that LXC should isolate memory available for containers like Vserver or FreeVPS do (memory + swap) if .cgroup.memory.* and lxc.cgroup.memory.memsw.* is set. Is there any possibility to make a patch for linux kernel / lxc-tools to show the limitations inside cointainers propertly? I think is a good idea and it should be apply as soon as possible. -- Krzysztof Taraszka ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <ac1c4bf20908230959j4cda58cel3bcf4f3822d50bb1-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <ac1c4bf20908230959j4cda58cel3bcf4f3822d50bb1-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2009-08-23 18:00 ` Daniel Lezcano [not found] ` <4A9183B2.7090005-GANU6spQydw@public.gmane.org> 0 siblings, 1 reply; 43+ messages in thread From: Daniel Lezcano @ 2009-08-23 18:00 UTC (permalink / raw) To: kt-S89nZTSLPHGGdvJs77BJ7Q Cc: Linux Containers, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Krzysztof Taraszka wrote: > 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> > >> Krzysztof Taraszka wrote: >> >>> Hello, >>> >>> I am running lxc on my debian unstable sandbox and I have a few question >>> about memory managament inside linux containers based on lxc project. >>> >>> I have got linux kernel 2.6.30.5 with enabled : >>> >>> +Resource counter >>> ++ Memory Resource Controller for Control Groups >>> +++ Memory Resource Controller Swap Extension(EXPERIMENTAL) >>> >>> lxc-checkconfig pass all checks. >>> >>> I read about cgroups memory managament (Documentation/cgroups/memory.txt) >>> and I tried to pass those value to my debian sandbox. >>> >>> And... >>> 'free -m' and 'top/htop' still show all available memory inside container >>> (also If I set 32M for lxc.cgroup.memory.limit_in_bytes and >>> lxc.cgroup.memory.usage_in_bytes; and 64M for >>> lxc.cgroup.memory.memsw.usage_in_bytes and >>> lxc.cgroup.memory.memsw.limit_in_bytes free and top show all resources). >>> >>> What I did wrong? Does the container always show all available memory >>> resources without cgroup limitations? >>> >> At the first glance I would say the configuration is correct. >> But AFAIR, the memory cgroup is not isolated, if you specify 32MB you will >> see all the memory available on the system either if you are not allowed to >> use more than 32MB. If you create a program which allocates 64MB within a >> container configured with 32MB, and you "touch" the pages (may be that can >> be done with one mmap call with the MAP_POPULATE option), you should see the >> application swapping and the "memory.failcnt" increasing. >> >> IMHO, showing all the memory available for the system instead of showing >> the allowed memory with the cgroup is weird but maybe there is a good reason >> to do that. >> >> > > Thank you Daniel for your reply. > I think that LXC should isolate memory available for containers like Vserver > or FreeVPS do (memory + swap) if .cgroup.memory.* and > lxc.cgroup.memory.memsw.* is set. > Is there any possibility to make a patch for linux kernel / lxc-tools to > show the limitations inside cointainers propertly? I think is a good idea > and it should be apply as soon as possible. Maybe a solution can be to add a new memory.meminfo file in the same format than /proc/meminfo, so it will be possible to mount --bind /cgroup/foo/memory.meminfo to /proc/meminfo for the container. ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <4A9183B2.7090005-GANU6spQydw@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <4A9183B2.7090005-GANU6spQydw@public.gmane.org> @ 2009-08-23 18:17 ` Krzysztof Taraszka [not found] ` <ac1c4bf20908231117sb180e78q3eed64db3573ec35-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 43+ messages in thread From: Krzysztof Taraszka @ 2009-08-23 18:17 UTC (permalink / raw) To: lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Linux Containers 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> > Krzysztof Taraszka wrote: > >> 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >> >> Krzysztof Taraszka wrote: >>> >>> Hello, >>>> >>>> I am running lxc on my debian unstable sandbox and I have a few question >>>> about memory managament inside linux containers based on lxc project. >>>> >>>> I have got linux kernel 2.6.30.5 with enabled : >>>> >>>> +Resource counter >>>> ++ Memory Resource Controller for Control Groups >>>> +++ Memory Resource Controller Swap Extension(EXPERIMENTAL) >>>> >>>> lxc-checkconfig pass all checks. >>>> >>>> I read about cgroups memory managament >>>> (Documentation/cgroups/memory.txt) >>>> and I tried to pass those value to my debian sandbox. >>>> >>>> And... >>>> 'free -m' and 'top/htop' still show all available memory inside >>>> container >>>> (also If I set 32M for lxc.cgroup.memory.limit_in_bytes and >>>> lxc.cgroup.memory.usage_in_bytes; and 64M for >>>> lxc.cgroup.memory.memsw.usage_in_bytes and >>>> lxc.cgroup.memory.memsw.limit_in_bytes free and top show all resources). >>>> >>>> What I did wrong? Does the container always show all available memory >>>> resources without cgroup limitations? >>>> >>>> At the first glance I would say the configuration is correct. >>> But AFAIR, the memory cgroup is not isolated, if you specify 32MB you >>> will >>> see all the memory available on the system either if you are not allowed >>> to >>> use more than 32MB. If you create a program which allocates 64MB within a >>> container configured with 32MB, and you "touch" the pages (may be that >>> can >>> be done with one mmap call with the MAP_POPULATE option), you should see >>> the >>> application swapping and the "memory.failcnt" increasing. >>> >>> IMHO, showing all the memory available for the system instead of showing >>> the allowed memory with the cgroup is weird but maybe there is a good >>> reason >>> to do that. >>> >>> >>> >> Thank you Daniel for your reply. >> I think that LXC should isolate memory available for containers like >> Vserver >> or FreeVPS do (memory + swap) if .cgroup.memory.* and >> lxc.cgroup.memory.memsw.* is set. >> Is there any possibility to make a patch for linux kernel / lxc-tools to >> show the limitations inside cointainers propertly? I think is a good idea >> and it should be apply as soon as possible. >> > > Maybe a solution can be to add a new memory.meminfo file in the same format > than /proc/meminfo, so it will be possible to mount --bind > /cgroup/foo/memory.meminfo to /proc/meminfo for the container. > Yes, I thought the same. This should allow the user-space tools based on /proc/meminfo (such as comand line "free") show limited information :) -- Krzysztof Taraszka ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <ac1c4bf20908231117sb180e78q3eed64db3573ec35-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <ac1c4bf20908231117sb180e78q3eed64db3573ec35-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2009-08-23 18:38 ` Krzysztof Taraszka [not found] ` <ac1c4bf20908231138j2ce7bb48v69a8ac8ede6bc314-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 43+ messages in thread From: Krzysztof Taraszka @ 2009-08-23 18:38 UTC (permalink / raw) To: lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Linux Containers 2009/8/23 Krzysztof Taraszka <krzysztof.taraszka-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org> > > > 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> > >> Krzysztof Taraszka wrote: >> >>> 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >>> >>> Krzysztof Taraszka wrote: >>>> >>>> Hello, >>>>> >>>>> I am running lxc on my debian unstable sandbox and I have a few >>>>> question >>>>> about memory managament inside linux containers based on lxc project. >>>>> >>>>> I have got linux kernel 2.6.30.5 with enabled : >>>>> >>>>> +Resource counter >>>>> ++ Memory Resource Controller for Control Groups >>>>> +++ Memory Resource Controller Swap Extension(EXPERIMENTAL) >>>>> >>>>> lxc-checkconfig pass all checks. >>>>> >>>>> I read about cgroups memory managament >>>>> (Documentation/cgroups/memory.txt) >>>>> and I tried to pass those value to my debian sandbox. >>>>> >>>>> And... >>>>> 'free -m' and 'top/htop' still show all available memory inside >>>>> container >>>>> (also If I set 32M for lxc.cgroup.memory.limit_in_bytes and >>>>> lxc.cgroup.memory.usage_in_bytes; and 64M for >>>>> lxc.cgroup.memory.memsw.usage_in_bytes and >>>>> lxc.cgroup.memory.memsw.limit_in_bytes free and top show all >>>>> resources). >>>>> >>>>> What I did wrong? Does the container always show all available memory >>>>> resources without cgroup limitations? >>>>> >>>>> At the first glance I would say the configuration is correct. >>>> But AFAIR, the memory cgroup is not isolated, if you specify 32MB you >>>> will >>>> see all the memory available on the system either if you are not allowed >>>> to >>>> use more than 32MB. If you create a program which allocates 64MB within >>>> a >>>> container configured with 32MB, and you "touch" the pages (may be that >>>> can >>>> be done with one mmap call with the MAP_POPULATE option), you should see >>>> the >>>> application swapping and the "memory.failcnt" increasing. >>>> >>>> IMHO, showing all the memory available for the system instead of showing >>>> the allowed memory with the cgroup is weird but maybe there is a good >>>> reason >>>> to do that. >>>> >>>> >>>> >>> Thank you Daniel for your reply. >>> I think that LXC should isolate memory available for containers like >>> Vserver >>> or FreeVPS do (memory + swap) if .cgroup.memory.* and >>> lxc.cgroup.memory.memsw.* is set. >>> Is there any possibility to make a patch for linux kernel / lxc-tools to >>> show the limitations inside cointainers propertly? I think is a good idea >>> and it should be apply as soon as possible. >>> >> >> Maybe a solution can be to add a new memory.meminfo file in the same >> format than /proc/meminfo, so it will be possible to mount --bind >> /cgroup/foo/memory.meminfo to /proc/meminfo for the container. >> > > Yes, I thought the same. This should allow the user-space tools based on > /proc/meminfo (such as comand line "free") show limited information :) > Hmmm... does the memory.stat is a good start point for make new one object memory.meminfo similar to /proc/meminfo? If so, I can play by my self with lxc-tools code. -- Krzysztof Taraszka ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <ac1c4bf20908231138j2ce7bb48v69a8ac8ede6bc314-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <ac1c4bf20908231138j2ce7bb48v69a8ac8ede6bc314-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2009-08-23 19:22 ` Krzysztof Taraszka [not found] ` <ac1c4bf20908231222t182e6ca6u716b98e13d85cbad-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 43+ messages in thread From: Krzysztof Taraszka @ 2009-08-23 19:22 UTC (permalink / raw) To: lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Linux Containers 2009/8/23 Krzysztof Taraszka <krzysztof.taraszka-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org> > 2009/8/23 Krzysztof Taraszka <krzysztof.taraszka-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org> > >> >> >> 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >> >>> Krzysztof Taraszka wrote: >>> >>>> 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >>>> >>>> Krzysztof Taraszka wrote: >>>>> >>>>> Hello, >>>>>> >>>>>> I am running lxc on my debian unstable sandbox and I have a few >>>>>> question >>>>>> about memory managament inside linux containers based on lxc project. >>>>>> >>>>>> I have got linux kernel 2.6.30.5 with enabled : >>>>>> >>>>>> +Resource counter >>>>>> ++ Memory Resource Controller for Control Groups >>>>>> +++ Memory Resource Controller Swap Extension(EXPERIMENTAL) >>>>>> >>>>>> lxc-checkconfig pass all checks. >>>>>> >>>>>> I read about cgroups memory managament >>>>>> (Documentation/cgroups/memory.txt) >>>>>> and I tried to pass those value to my debian sandbox. >>>>>> >>>>>> And... >>>>>> 'free -m' and 'top/htop' still show all available memory inside >>>>>> container >>>>>> (also If I set 32M for lxc.cgroup.memory.limit_in_bytes and >>>>>> lxc.cgroup.memory.usage_in_bytes; and 64M for >>>>>> lxc.cgroup.memory.memsw.usage_in_bytes and >>>>>> lxc.cgroup.memory.memsw.limit_in_bytes free and top show all >>>>>> resources). >>>>>> >>>>>> What I did wrong? Does the container always show all available memory >>>>>> resources without cgroup limitations? >>>>>> >>>>>> At the first glance I would say the configuration is correct. >>>>> But AFAIR, the memory cgroup is not isolated, if you specify 32MB you >>>>> will >>>>> see all the memory available on the system either if you are not >>>>> allowed to >>>>> use more than 32MB. If you create a program which allocates 64MB within >>>>> a >>>>> container configured with 32MB, and you "touch" the pages (may be that >>>>> can >>>>> be done with one mmap call with the MAP_POPULATE option), you should >>>>> see the >>>>> application swapping and the "memory.failcnt" increasing. >>>>> >>>>> IMHO, showing all the memory available for the system instead of >>>>> showing >>>>> the allowed memory with the cgroup is weird but maybe there is a good >>>>> reason >>>>> to do that. >>>>> >>>>> >>>>> >>>> Thank you Daniel for your reply. >>>> I think that LXC should isolate memory available for containers like >>>> Vserver >>>> or FreeVPS do (memory + swap) if .cgroup.memory.* and >>>> lxc.cgroup.memory.memsw.* is set. >>>> Is there any possibility to make a patch for linux kernel / lxc-tools to >>>> show the limitations inside cointainers propertly? I think is a good >>>> idea >>>> and it should be apply as soon as possible. >>>> >>> >>> Maybe a solution can be to add a new memory.meminfo file in the same >>> format than /proc/meminfo, so it will be possible to mount --bind >>> /cgroup/foo/memory.meminfo to /proc/meminfo for the container. >>> >> >> Yes, I thought the same. This should allow the user-space tools based on >> /proc/meminfo (such as comand line "free") show limited information :) >> > > Hmmm... does the memory.stat is a good start point for make new one object > memory.meminfo similar to /proc/meminfo? If so, I can play by my self with > lxc-tools code. > Hmmm... Daniel, I have got a question (that do I thinking in the right way). here is an output from /proc/meminfo from openvz: MemTotal: 262144 kB MemFree: 232560 kB Buffers: 0 kB Cached: 0 kB SwapCached: 0 kB Active: 0 kB Inactive: 0 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 262144 kB LowFree: 232560 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 0 kB Writeback: 0 kB AnonPages: 0 kB Mapped: 0 kB Slab: 0 kB SReclaimable: 0 kB SUnreclaim: 0 kB PageTables: 0 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 0 kB Committed_AS: 0 kB VmallocTotal: 0 kB VmallocUsed: 0 kB VmallocChunk: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB most of values are 0. I have an question about SwapTotal and SwapFree for LXC. As I thinking that: MemTotal might be: hierarchical_memory_limit MemFree might be: hierarchical_memory_limit - cache the SwapTotal might be: hierarchical_memsw_limit SwapFree might be: hierarchical_memsw_limit - rss rss - # of bytes of anonymous and swap cache memory I don't know at all that hierarchical_memsw_limit is an good value for swap total, because as I read it is a mem+swap at all. Does the lxc memory.meminfo might look like above? Where can I get the Hugepagesize? -- Krzysztof Taraszka ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <ac1c4bf20908231222t182e6ca6u716b98e13d85cbad-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <ac1c4bf20908231222t182e6ca6u716b98e13d85cbad-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2009-08-23 20:05 ` Daniel Lezcano [not found] ` <4A91A103.6020207-GANU6spQydw@public.gmane.org> 0 siblings, 1 reply; 43+ messages in thread From: Daniel Lezcano @ 2009-08-23 20:05 UTC (permalink / raw) To: kt-S89nZTSLPHGGdvJs77BJ7Q Cc: Linux Containers, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Krzysztof Taraszka wrote: > 2009/8/23 Krzysztof Taraszka <krzysztof.taraszka-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org> > > >> 2009/8/23 Krzysztof Taraszka <krzysztof.taraszka-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org> >> >> >>> 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >>> >>> >>>> Krzysztof Taraszka wrote: >>>> >>>> >>>>> 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >>>>> >>>>> Krzysztof Taraszka wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>>> I am running lxc on my debian unstable sandbox and I have a few >>>>>>> question >>>>>>> about memory managament inside linux containers based on lxc project. >>>>>>> >>>>>>> I have got linux kernel 2.6.30.5 with enabled : >>>>>>> >>>>>>> +Resource counter >>>>>>> ++ Memory Resource Controller for Control Groups >>>>>>> +++ Memory Resource Controller Swap Extension(EXPERIMENTAL) >>>>>>> >>>>>>> lxc-checkconfig pass all checks. >>>>>>> >>>>>>> I read about cgroups memory managament >>>>>>> (Documentation/cgroups/memory.txt) >>>>>>> and I tried to pass those value to my debian sandbox. >>>>>>> >>>>>>> And... >>>>>>> 'free -m' and 'top/htop' still show all available memory inside >>>>>>> container >>>>>>> (also If I set 32M for lxc.cgroup.memory.limit_in_bytes and >>>>>>> lxc.cgroup.memory.usage_in_bytes; and 64M for >>>>>>> lxc.cgroup.memory.memsw.usage_in_bytes and >>>>>>> lxc.cgroup.memory.memsw.limit_in_bytes free and top show all >>>>>>> resources). >>>>>>> >>>>>>> What I did wrong? Does the container always show all available memory >>>>>>> resources without cgroup limitations? >>>>>>> >>>>>>> At the first glance I would say the configuration is correct. >>>>>>> >>>>>> But AFAIR, the memory cgroup is not isolated, if you specify 32MB you >>>>>> will >>>>>> see all the memory available on the system either if you are not >>>>>> allowed to >>>>>> use more than 32MB. If you create a program which allocates 64MB within >>>>>> a >>>>>> container configured with 32MB, and you "touch" the pages (may be that >>>>>> can >>>>>> be done with one mmap call with the MAP_POPULATE option), you should >>>>>> see the >>>>>> application swapping and the "memory.failcnt" increasing. >>>>>> >>>>>> IMHO, showing all the memory available for the system instead of >>>>>> showing >>>>>> the allowed memory with the cgroup is weird but maybe there is a good >>>>>> reason >>>>>> to do that. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Thank you Daniel for your reply. >>>>> I think that LXC should isolate memory available for containers like >>>>> Vserver >>>>> or FreeVPS do (memory + swap) if .cgroup.memory.* and >>>>> lxc.cgroup.memory.memsw.* is set. >>>>> Is there any possibility to make a patch for linux kernel / lxc-tools to >>>>> show the limitations inside cointainers propertly? I think is a good >>>>> idea >>>>> and it should be apply as soon as possible. >>>>> >>>>> >>>> Maybe a solution can be to add a new memory.meminfo file in the same >>>> format than /proc/meminfo, so it will be possible to mount --bind >>>> /cgroup/foo/memory.meminfo to /proc/meminfo for the container. >>>> >>>> >>> Yes, I thought the same. This should allow the user-space tools based on >>> /proc/meminfo (such as comand line "free") show limited information :) >>> >>> >> Hmmm... does the memory.stat is a good start point for make new one object >> memory.meminfo similar to /proc/meminfo? If so, I can play by my self with >> lxc-tools code. >> >> > > > Hmmm... Daniel, I have got a question (that do I thinking in the right way). > here is an output from /proc/meminfo from openvz: > > > MemTotal: 262144 kB > MemFree: 232560 kB > Buffers: 0 kB > Cached: 0 kB > SwapCached: 0 kB > Active: 0 kB > Inactive: 0 kB > HighTotal: 0 kB > HighFree: 0 kB > LowTotal: 262144 kB > LowFree: 232560 kB > SwapTotal: 0 kB > SwapFree: 0 kB > Dirty: 0 kB > Writeback: 0 kB > AnonPages: 0 kB > Mapped: 0 kB > Slab: 0 kB > SReclaimable: 0 kB > SUnreclaim: 0 kB > PageTables: 0 kB > NFS_Unstable: 0 kB > Bounce: 0 kB > WritebackTmp: 0 kB > CommitLimit: 0 kB > Committed_AS: 0 kB > VmallocTotal: 0 kB > VmallocUsed: 0 kB > VmallocChunk: 0 kB > HugePages_Total: 0 > HugePages_Free: 0 > HugePages_Rsvd: 0 > HugePages_Surp: 0 > Hugepagesize: 2048 kB > > most of values are 0. > > I have an question about SwapTotal and SwapFree for LXC. > As I thinking that: > > MemTotal might be: hierarchical_memory_limit > MemFree might be: hierarchical_memory_limit - cache > I am not a memory expert, but isn't MemFree : hierarchical_memory_limit - rss ? > the > > SwapTotal might be: hierarchical_memsw_limit > SwapFree might be: hierarchical_memsw_limit - rss > > rss - # of bytes of anonymous and swap cache memory > I don't know at all that hierarchical_memsw_limit is an good value for swap > total, because as I read it is a mem+swap at all. > > Does the lxc memory.meminfo might look like above? Where can I get the > Hugepagesize? > Right, I agree most of the interesting information to create a memory.meminfo is already there in another file and another format. Probably some informations in memory.stat can be moved to memory.meminfo and this one can be step by step filled with cgroup memory statistic informations. IMO, if the memory controller displays memory statistics like a proc/meminfo file format, that will make consistency for these informations and make trivial the isolation/virtualization with a simple mount-bind. ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <4A91A103.6020207-GANU6spQydw@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <4A91A103.6020207-GANU6spQydw@public.gmane.org> @ 2009-08-23 20:18 ` Krzysztof Taraszka [not found] ` <ac1c4bf20908231318v1586c2ciffd3df5fe1b70c20-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 43+ messages in thread From: Krzysztof Taraszka @ 2009-08-23 20:18 UTC (permalink / raw) To: Daniel Lezcano Cc: Linux Containers, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> > Krzysztof Taraszka wrote: > >> 2009/8/23 Krzysztof Taraszka <krzysztof.taraszka-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org> >> >> >> >>> 2009/8/23 Krzysztof Taraszka <krzysztof.taraszka-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org> >>> >>> >>> >>>> 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >>>> >>>> >>>> >>>>> Krzysztof Taraszka wrote: >>>>> >>>>> >>>>> >>>>>> 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >>>>>> >>>>>> Krzysztof Taraszka wrote: >>>>>> >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> >>>>>>>> I am running lxc on my debian unstable sandbox and I have a few >>>>>>>> question >>>>>>>> about memory managament inside linux containers based on lxc >>>>>>>> project. >>>>>>>> >>>>>>>> I have got linux kernel 2.6.30.5 with enabled : >>>>>>>> >>>>>>>> +Resource counter >>>>>>>> ++ Memory Resource Controller for Control Groups >>>>>>>> +++ Memory Resource Controller Swap Extension(EXPERIMENTAL) >>>>>>>> >>>>>>>> lxc-checkconfig pass all checks. >>>>>>>> >>>>>>>> I read about cgroups memory managament >>>>>>>> (Documentation/cgroups/memory.txt) >>>>>>>> and I tried to pass those value to my debian sandbox. >>>>>>>> >>>>>>>> And... >>>>>>>> 'free -m' and 'top/htop' still show all available memory inside >>>>>>>> container >>>>>>>> (also If I set 32M for lxc.cgroup.memory.limit_in_bytes and >>>>>>>> lxc.cgroup.memory.usage_in_bytes; and 64M for >>>>>>>> lxc.cgroup.memory.memsw.usage_in_bytes and >>>>>>>> lxc.cgroup.memory.memsw.limit_in_bytes free and top show all >>>>>>>> resources). >>>>>>>> >>>>>>>> What I did wrong? Does the container always show all available >>>>>>>> memory >>>>>>>> resources without cgroup limitations? >>>>>>>> >>>>>>>> At the first glance I would say the configuration is correct. >>>>>>>> >>>>>>>> >>>>>>> But AFAIR, the memory cgroup is not isolated, if you specify 32MB you >>>>>>> will >>>>>>> see all the memory available on the system either if you are not >>>>>>> allowed to >>>>>>> use more than 32MB. If you create a program which allocates 64MB >>>>>>> within >>>>>>> a >>>>>>> container configured with 32MB, and you "touch" the pages (may be >>>>>>> that >>>>>>> can >>>>>>> be done with one mmap call with the MAP_POPULATE option), you should >>>>>>> see the >>>>>>> application swapping and the "memory.failcnt" increasing. >>>>>>> >>>>>>> IMHO, showing all the memory available for the system instead of >>>>>>> showing >>>>>>> the allowed memory with the cgroup is weird but maybe there is a good >>>>>>> reason >>>>>>> to do that. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Thank you Daniel for your reply. >>>>>> I think that LXC should isolate memory available for containers like >>>>>> Vserver >>>>>> or FreeVPS do (memory + swap) if .cgroup.memory.* and >>>>>> lxc.cgroup.memory.memsw.* is set. >>>>>> Is there any possibility to make a patch for linux kernel / lxc-tools >>>>>> to >>>>>> show the limitations inside cointainers propertly? I think is a good >>>>>> idea >>>>>> and it should be apply as soon as possible. >>>>>> >>>>>> >>>>>> >>>>> Maybe a solution can be to add a new memory.meminfo file in the same >>>>> format than /proc/meminfo, so it will be possible to mount --bind >>>>> /cgroup/foo/memory.meminfo to /proc/meminfo for the container. >>>>> >>>>> >>>>> >>>> Yes, I thought the same. This should allow the user-space tools based on >>>> /proc/meminfo (such as comand line "free") show limited information :) >>>> >>>> >>>> >>> Hmmm... does the memory.stat is a good start point for make new one >>> object >>> memory.meminfo similar to /proc/meminfo? If so, I can play by my self >>> with >>> lxc-tools code. >>> >>> >>> >> >> >> Hmmm... Daniel, I have got a question (that do I thinking in the right >> way). >> here is an output from /proc/meminfo from openvz: >> >> >> MemTotal: 262144 kB >> MemFree: 232560 kB >> Buffers: 0 kB >> Cached: 0 kB >> SwapCached: 0 kB >> Active: 0 kB >> Inactive: 0 kB >> HighTotal: 0 kB >> HighFree: 0 kB >> LowTotal: 262144 kB >> LowFree: 232560 kB >> SwapTotal: 0 kB >> SwapFree: 0 kB >> Dirty: 0 kB >> Writeback: 0 kB >> AnonPages: 0 kB >> Mapped: 0 kB >> Slab: 0 kB >> SReclaimable: 0 kB >> SUnreclaim: 0 kB >> PageTables: 0 kB >> NFS_Unstable: 0 kB >> Bounce: 0 kB >> WritebackTmp: 0 kB >> CommitLimit: 0 kB >> Committed_AS: 0 kB >> VmallocTotal: 0 kB >> VmallocUsed: 0 kB >> VmallocChunk: 0 kB >> HugePages_Total: 0 >> HugePages_Free: 0 >> HugePages_Rsvd: 0 >> HugePages_Surp: 0 >> Hugepagesize: 2048 kB >> >> most of values are 0. >> >> I have an question about SwapTotal and SwapFree for LXC. >> As I thinking that: >> >> MemTotal might be: hierarchical_memory_limit >> MemFree might be: hierarchical_memory_limit - cache >> >> > I am not a memory expert, but isn't MemFree : hierarchical_memory_limit - > rss ? > >> the >> >> SwapTotal might be: hierarchical_memsw_limit >> SwapFree might be: hierarchical_memsw_limit - rss >> >> rss - # of bytes of anonymous and swap cache memory >> I don't know at all that hierarchical_memsw_limit is an good value for >> swap >> total, because as I read it is a mem+swap at all. >> >> Does the lxc memory.meminfo might look like above? Where can I get the >> Hugepagesize? >> >> > Right, I agree most of the interesting information to create a > memory.meminfo is already there in another file and another format. Probably > some informations in memory.stat can be moved to memory.meminfo and this one > can be step by step filled with cgroup memory statistic informations. IMO, > if the memory controller displays memory statistics like a proc/meminfo file > format, that will make consistency for these informations and make trivial > the isolation/virtualization with a simple mount-bind. > > > Hmm.. might be. Right now I am looking for and writing new function in mm/memcontrol.c file for writing some stats in memory.meminfo file for tests. Dirty and ugly part of code, but if it will work as we thought (mount-bind) and as you wrote above, that will be very simple. I am going to look how does the /proc/meminfo is doing by the openvz. mm/memcontrol.c was wrote by xemul from openvz and balbir from ibm. If I am thinking in the right way, guys from openvz made their own patch for meminfo based on the mm/memcontrol.c. If I am wrong - where do they taking meminfo data? :) -- Krzysztof Taraszka ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <ac1c4bf20908231318v1586c2ciffd3df5fe1b70c20-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <ac1c4bf20908231318v1586c2ciffd3df5fe1b70c20-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2009-08-23 21:00 ` Daniel Lezcano [not found] ` <4A91ADE1.9090204-GANU6spQydw@public.gmane.org> 0 siblings, 1 reply; 43+ messages in thread From: Daniel Lezcano @ 2009-08-23 21:00 UTC (permalink / raw) To: kt-S89nZTSLPHGGdvJs77BJ7Q Cc: Linux Containers, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Krzysztof Taraszka wrote: > 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> > >> Krzysztof Taraszka wrote: >> >>> 2009/8/23 Krzysztof Taraszka <krzysztof.taraszka-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org> >>> >>> >>> >>>> 2009/8/23 Krzysztof Taraszka <krzysztof.taraszka-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org> >>>> >>>> >>>> >>>>> 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >>>>> >>>>> >>>>> >>>>>> Krzysztof Taraszka wrote: >>>>>> >>>>>> >>>>>> >>>>>>> 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >>>>>>> >>>>>>> Krzysztof Taraszka wrote: >>>>>>> >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> >>>>>>>>> I am running lxc on my debian unstable sandbox and I have a few >>>>>>>>> question >>>>>>>>> about memory managament inside linux containers based on lxc >>>>>>>>> project. >>>>>>>>> >>>>>>>>> I have got linux kernel 2.6.30.5 with enabled : >>>>>>>>> >>>>>>>>> +Resource counter >>>>>>>>> ++ Memory Resource Controller for Control Groups >>>>>>>>> +++ Memory Resource Controller Swap Extension(EXPERIMENTAL) >>>>>>>>> >>>>>>>>> lxc-checkconfig pass all checks. >>>>>>>>> >>>>>>>>> I read about cgroups memory managament >>>>>>>>> (Documentation/cgroups/memory.txt) >>>>>>>>> and I tried to pass those value to my debian sandbox. >>>>>>>>> >>>>>>>>> And... >>>>>>>>> 'free -m' and 'top/htop' still show all available memory inside >>>>>>>>> container >>>>>>>>> (also If I set 32M for lxc.cgroup.memory.limit_in_bytes and >>>>>>>>> lxc.cgroup.memory.usage_in_bytes; and 64M for >>>>>>>>> lxc.cgroup.memory.memsw.usage_in_bytes and >>>>>>>>> lxc.cgroup.memory.memsw.limit_in_bytes free and top show all >>>>>>>>> resources). >>>>>>>>> >>>>>>>>> What I did wrong? Does the container always show all available >>>>>>>>> memory >>>>>>>>> resources without cgroup limitations? >>>>>>>>> >>>>>>>>> At the first glance I would say the configuration is correct. >>>>>>>>> >>>>>>>>> >>>>>>>> But AFAIR, the memory cgroup is not isolated, if you specify 32MB you >>>>>>>> will >>>>>>>> see all the memory available on the system either if you are not >>>>>>>> allowed to >>>>>>>> use more than 32MB. If you create a program which allocates 64MB >>>>>>>> within >>>>>>>> a >>>>>>>> container configured with 32MB, and you "touch" the pages (may be >>>>>>>> that >>>>>>>> can >>>>>>>> be done with one mmap call with the MAP_POPULATE option), you should >>>>>>>> see the >>>>>>>> application swapping and the "memory.failcnt" increasing. >>>>>>>> >>>>>>>> IMHO, showing all the memory available for the system instead of >>>>>>>> showing >>>>>>>> the allowed memory with the cgroup is weird but maybe there is a good >>>>>>>> reason >>>>>>>> to do that. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Thank you Daniel for your reply. >>>>>>> I think that LXC should isolate memory available for containers like >>>>>>> Vserver >>>>>>> or FreeVPS do (memory + swap) if .cgroup.memory.* and >>>>>>> lxc.cgroup.memory.memsw.* is set. >>>>>>> Is there any possibility to make a patch for linux kernel / lxc-tools >>>>>>> to >>>>>>> show the limitations inside cointainers propertly? I think is a good >>>>>>> idea >>>>>>> and it should be apply as soon as possible. >>>>>>> >>>>>>> >>>>>>> >>>>>> Maybe a solution can be to add a new memory.meminfo file in the same >>>>>> format than /proc/meminfo, so it will be possible to mount --bind >>>>>> /cgroup/foo/memory.meminfo to /proc/meminfo for the container. >>>>>> >>>>>> >>>>>> >>>>> Yes, I thought the same. This should allow the user-space tools based on >>>>> /proc/meminfo (such as comand line "free") show limited information :) >>>>> >>>>> >>>>> >>>> Hmmm... does the memory.stat is a good start point for make new one >>>> object >>>> memory.meminfo similar to /proc/meminfo? If so, I can play by my self >>>> with >>>> lxc-tools code. >>>> >>>> >>>> >>> >>> Hmmm... Daniel, I have got a question (that do I thinking in the right >>> way). >>> here is an output from /proc/meminfo from openvz: >>> >>> >>> MemTotal: 262144 kB >>> MemFree: 232560 kB >>> Buffers: 0 kB >>> Cached: 0 kB >>> SwapCached: 0 kB >>> Active: 0 kB >>> Inactive: 0 kB >>> HighTotal: 0 kB >>> HighFree: 0 kB >>> LowTotal: 262144 kB >>> LowFree: 232560 kB >>> SwapTotal: 0 kB >>> SwapFree: 0 kB >>> Dirty: 0 kB >>> Writeback: 0 kB >>> AnonPages: 0 kB >>> Mapped: 0 kB >>> Slab: 0 kB >>> SReclaimable: 0 kB >>> SUnreclaim: 0 kB >>> PageTables: 0 kB >>> NFS_Unstable: 0 kB >>> Bounce: 0 kB >>> WritebackTmp: 0 kB >>> CommitLimit: 0 kB >>> Committed_AS: 0 kB >>> VmallocTotal: 0 kB >>> VmallocUsed: 0 kB >>> VmallocChunk: 0 kB >>> HugePages_Total: 0 >>> HugePages_Free: 0 >>> HugePages_Rsvd: 0 >>> HugePages_Surp: 0 >>> Hugepagesize: 2048 kB >>> >>> most of values are 0. >>> >>> I have an question about SwapTotal and SwapFree for LXC. >>> As I thinking that: >>> >>> MemTotal might be: hierarchical_memory_limit >>> MemFree might be: hierarchical_memory_limit - cache >>> >>> >> I am not a memory expert, but isn't MemFree : hierarchical_memory_limit - >> rss ? >> >>> the >>> >>> SwapTotal might be: hierarchical_memsw_limit >>> SwapFree might be: hierarchical_memsw_limit - rss >>> >>> rss - # of bytes of anonymous and swap cache memory >>> I don't know at all that hierarchical_memsw_limit is an good value for >>> swap >>> total, because as I read it is a mem+swap at all. >>> >>> Does the lxc memory.meminfo might look like above? Where can I get the >>> Hugepagesize? >>> >>> >> Right, I agree most of the interesting information to create a >> memory.meminfo is already there in another file and another format. Probably >> some informations in memory.stat can be moved to memory.meminfo and this one >> can be step by step filled with cgroup memory statistic informations. IMO, >> if the memory controller displays memory statistics like a proc/meminfo file >> format, that will make consistency for these informations and make trivial >> the isolation/virtualization with a simple mount-bind. >> >> >> > Hmm.. > might be. Right now I am looking for and writing new function in > mm/memcontrol.c file for writing some stats in memory.meminfo file for > tests. > Dirty and ugly part of code, but if it will work as we thought (mount-bind) > and as you wrote above, that will be very simple. > I am going to look how does the /proc/meminfo is doing by the openvz. > mm/memcontrol.c was wrote by xemul from openvz and balbir from ibm. > If I am thinking in the right way, guys from openvz made their own patch for > meminfo based on the mm/memcontrol.c. If I am wrong - where do they taking > meminfo data? :) I did this ugly patch patch for MemTotal/MemFree - maybe wrong :) Index: linux-2.6/mm/memcontrol.c =================================================================== --- linux-2.6.orig/mm/memcontrol.c 2009-06-23 12:00:52.000000000 +0200 +++ linux-2.6/mm/memcontrol.c 2009-08-23 22:49:02.000000000 +0200 @@ -2200,6 +2200,27 @@ static int mem_cgroup_swappiness_write(s } +static int mem_cgroup_meminfo(struct cgroup *cgrp, struct cftype *cft, + struct seq_file *seq) +{ +#define K(x) ((x) << 10) + + struct mem_cgroup *mem_cont = mem_cgroup_from_cont(cgrp); + struct mcs_total_stat mystat = { }; + unsigned long long limit, memsw_limit; + + mem_cgroup_get_local_stat(mem_cont, &mystat); + memcg_get_hierarchical_limit(mem_cont, &limit, &memsw_limit); + + seq_printf(seq, + "MemTotal: %8llu kB\n" + "MemFree: %8llu kB\n", + limit / 1024, (limit - mystat.stat[MCS_RSS]) / 1024); + + return 0; +#undef K +} + static struct cftype mem_cgroup_files[] = { { .name = "usage_in_bytes", @@ -2242,6 +2263,10 @@ static struct cftype mem_cgroup_files[] .read_u64 = mem_cgroup_swappiness_read, .write_u64 = mem_cgroup_swappiness_write, }, + { + .name = "meminfo", + .read_seq_string = mem_cgroup_meminfo, + }, }; #ifdef CONFIG_CGROUP_MEM_RES_CTLR_SWAP With the lxc tools I did: lxc-execute -n foo /bin/bash echo 268435456 > /cgroup/foo/memory.limit_in_bytes mount --bind /cgroup/foo/memory.meminfo /proc/meminfo for i in $(seq 1 100); do sleep 3600 & done And the result for "free" is: free: total used free shared buffers cached Mem: 262144 9692 252452 0 0 0 -/+ buffers/cache: 9692 252452 Swap: 0 0 0 and for "top": top - 22:57:37 up 8 min, 1 user, load average: 0.00, 0.02, 0.00 Tasks: 104 total, 1 running, 103 sleeping, 0 stopped, 0 zombie Cpu(s): 0.3%us, 1.0%sy, 0.0%ni, 98.4%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st Mem: 262144k total, 9864k used, 252280k free, 0k buffers Swap: 0k total, 0k used, 0k free, 0k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 337 root 20 0 14748 1132 872 R 1.0 0.4 0:00.24 top 1 root 20 0 8136 484 408 S 0.0 0.2 0:00.00 lxc-init 2 root 20 0 89980 1724 1348 S 0.0 0.7 0:00.70 bash 25 root 20 0 86916 612 524 S 0.0 0.2 0:00.00 sleep 232 root 20 0 86916 616 524 S 0.0 0.2 0:00.00 sleep 233 root 20 0 86916 612 524 S 0.0 0.2 0:00.00 sleep 234 root 20 0 86916 612 524 S 0.0 0.2 0:00.00 sleep 235 root 20 0 86916 612 524 S 0.0 0.2 0:00.00 sleep ..... :) ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <4A91ADE1.9090204-GANU6spQydw@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <4A91ADE1.9090204-GANU6spQydw@public.gmane.org> @ 2009-08-23 21:12 ` Krzysztof Taraszka [not found] ` <ac1c4bf20908231412m634fdf9h686f6bd24eb95a14-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2009-08-24 0:48 ` Krzysztof Taraszka 2009-08-24 0:58 ` Krzysztof Taraszka 2 siblings, 1 reply; 43+ messages in thread From: Krzysztof Taraszka @ 2009-08-23 21:12 UTC (permalink / raw) To: Daniel Lezcano Cc: Linux Containers, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f :) excelent :) my ugly patch printing right now undefinied data but the idea was the same :) how about memsw_limit for swap? :> I am looking for swap usage statistics from cgroup right now from memcontrol.c :) but as you did the idea is good and should be add to the kernel and lxc-tools :) 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> > Krzysztof Taraszka wrote: > >> 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >> >> Krzysztof Taraszka wrote: >>> >>> 2009/8/23 Krzysztof Taraszka <krzysztof.taraszka-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org> >>>> >>>> >>>> >>>> 2009/8/23 Krzysztof Taraszka <krzysztof.taraszka-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org> >>>>> >>>>> >>>>> >>>>> 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >>>>>> >>>>>> >>>>>> >>>>>> Krzysztof Taraszka wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >>>>>>>> >>>>>>>> Krzysztof Taraszka wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hello, >>>>>>>>> >>>>>>>>> >>>>>>>>> I am running lxc on my debian unstable sandbox and I have a few >>>>>>>>>> question >>>>>>>>>> about memory managament inside linux containers based on lxc >>>>>>>>>> project. >>>>>>>>>> >>>>>>>>>> I have got linux kernel 2.6.30.5 with enabled : >>>>>>>>>> >>>>>>>>>> +Resource counter >>>>>>>>>> ++ Memory Resource Controller for Control Groups >>>>>>>>>> +++ Memory Resource Controller Swap Extension(EXPERIMENTAL) >>>>>>>>>> >>>>>>>>>> lxc-checkconfig pass all checks. >>>>>>>>>> >>>>>>>>>> I read about cgroups memory managament >>>>>>>>>> (Documentation/cgroups/memory.txt) >>>>>>>>>> and I tried to pass those value to my debian sandbox. >>>>>>>>>> >>>>>>>>>> And... >>>>>>>>>> 'free -m' and 'top/htop' still show all available memory inside >>>>>>>>>> container >>>>>>>>>> (also If I set 32M for lxc.cgroup.memory.limit_in_bytes and >>>>>>>>>> lxc.cgroup.memory.usage_in_bytes; and 64M for >>>>>>>>>> lxc.cgroup.memory.memsw.usage_in_bytes and >>>>>>>>>> lxc.cgroup.memory.memsw.limit_in_bytes free and top show all >>>>>>>>>> resources). >>>>>>>>>> >>>>>>>>>> What I did wrong? Does the container always show all available >>>>>>>>>> memory >>>>>>>>>> resources without cgroup limitations? >>>>>>>>>> >>>>>>>>>> At the first glance I would say the configuration is correct. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> But AFAIR, the memory cgroup is not isolated, if you specify 32MB >>>>>>>>> you >>>>>>>>> will >>>>>>>>> see all the memory available on the system either if you are not >>>>>>>>> allowed to >>>>>>>>> use more than 32MB. If you create a program which allocates 64MB >>>>>>>>> within >>>>>>>>> a >>>>>>>>> container configured with 32MB, and you "touch" the pages (may be >>>>>>>>> that >>>>>>>>> can >>>>>>>>> be done with one mmap call with the MAP_POPULATE option), you >>>>>>>>> should >>>>>>>>> see the >>>>>>>>> application swapping and the "memory.failcnt" increasing. >>>>>>>>> >>>>>>>>> IMHO, showing all the memory available for the system instead of >>>>>>>>> showing >>>>>>>>> the allowed memory with the cgroup is weird but maybe there is a >>>>>>>>> good >>>>>>>>> reason >>>>>>>>> to do that. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thank you Daniel for your reply. >>>>>>>> I think that LXC should isolate memory available for containers like >>>>>>>> Vserver >>>>>>>> or FreeVPS do (memory + swap) if .cgroup.memory.* and >>>>>>>> lxc.cgroup.memory.memsw.* is set. >>>>>>>> Is there any possibility to make a patch for linux kernel / >>>>>>>> lxc-tools >>>>>>>> to >>>>>>>> show the limitations inside cointainers propertly? I think is a good >>>>>>>> idea >>>>>>>> and it should be apply as soon as possible. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Maybe a solution can be to add a new memory.meminfo file in the >>>>>>> same >>>>>>> format than /proc/meminfo, so it will be possible to mount --bind >>>>>>> /cgroup/foo/memory.meminfo to /proc/meminfo for the container. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Yes, I thought the same. This should allow the user-space tools >>>>>> based on >>>>>> /proc/meminfo (such as comand line "free") show limited information :) >>>>>> >>>>>> >>>>>> >>>>>> Hmmm... does the memory.stat is a good start point for make new one >>>>> object >>>>> memory.meminfo similar to /proc/meminfo? If so, I can play by my self >>>>> with >>>>> lxc-tools code. >>>>> >>>>> >>>>> >>>>> >>>> Hmmm... Daniel, I have got a question (that do I thinking in the right >>>> way). >>>> here is an output from /proc/meminfo from openvz: >>>> >>>> >>>> MemTotal: 262144 kB >>>> MemFree: 232560 kB >>>> Buffers: 0 kB >>>> Cached: 0 kB >>>> SwapCached: 0 kB >>>> Active: 0 kB >>>> Inactive: 0 kB >>>> HighTotal: 0 kB >>>> HighFree: 0 kB >>>> LowTotal: 262144 kB >>>> LowFree: 232560 kB >>>> SwapTotal: 0 kB >>>> SwapFree: 0 kB >>>> Dirty: 0 kB >>>> Writeback: 0 kB >>>> AnonPages: 0 kB >>>> Mapped: 0 kB >>>> Slab: 0 kB >>>> SReclaimable: 0 kB >>>> SUnreclaim: 0 kB >>>> PageTables: 0 kB >>>> NFS_Unstable: 0 kB >>>> Bounce: 0 kB >>>> WritebackTmp: 0 kB >>>> CommitLimit: 0 kB >>>> Committed_AS: 0 kB >>>> VmallocTotal: 0 kB >>>> VmallocUsed: 0 kB >>>> VmallocChunk: 0 kB >>>> HugePages_Total: 0 >>>> HugePages_Free: 0 >>>> HugePages_Rsvd: 0 >>>> HugePages_Surp: 0 >>>> Hugepagesize: 2048 kB >>>> >>>> most of values are 0. >>>> >>>> I have an question about SwapTotal and SwapFree for LXC. >>>> As I thinking that: >>>> >>>> MemTotal might be: hierarchical_memory_limit >>>> MemFree might be: hierarchical_memory_limit - cache >>>> >>>> >>>> I am not a memory expert, but isn't MemFree : hierarchical_memory_limit >>> - >>> rss ? >>> >>> the >>>> >>>> SwapTotal might be: hierarchical_memsw_limit >>>> SwapFree might be: hierarchical_memsw_limit - rss >>>> >>>> rss - # of bytes of anonymous and swap cache memory >>>> I don't know at all that hierarchical_memsw_limit is an good value for >>>> swap >>>> total, because as I read it is a mem+swap at all. >>>> >>>> Does the lxc memory.meminfo might look like above? Where can I get the >>>> Hugepagesize? >>>> >>>> >>>> Right, I agree most of the interesting information to create a >>> memory.meminfo is already there in another file and another format. >>> Probably >>> some informations in memory.stat can be moved to memory.meminfo and this >>> one >>> can be step by step filled with cgroup memory statistic informations. >>> IMO, >>> if the memory controller displays memory statistics like a proc/meminfo >>> file >>> format, that will make consistency for these informations and make >>> trivial >>> the isolation/virtualization with a simple mount-bind. >>> >>> >>> >>> Hmm.. >> might be. Right now I am looking for and writing new function in >> mm/memcontrol.c file for writing some stats in memory.meminfo file for >> tests. >> Dirty and ugly part of code, but if it will work as we thought >> (mount-bind) >> and as you wrote above, that will be very simple. >> I am going to look how does the /proc/meminfo is doing by the openvz. >> mm/memcontrol.c was wrote by xemul from openvz and balbir from ibm. >> If I am thinking in the right way, guys from openvz made their own patch >> for >> meminfo based on the mm/memcontrol.c. If I am wrong - where do they taking >> meminfo data? :) >> > > I did this ugly patch patch for MemTotal/MemFree - maybe wrong :) > > Index: linux-2.6/mm/memcontrol.c > =================================================================== > --- linux-2.6.orig/mm/memcontrol.c 2009-06-23 12:00:52.000000000 +0200 > +++ linux-2.6/mm/memcontrol.c 2009-08-23 22:49:02.000000000 +0200 > @@ -2200,6 +2200,27 @@ static int mem_cgroup_swappiness_write(s > } > > > +static int mem_cgroup_meminfo(struct cgroup *cgrp, struct cftype *cft, > + struct seq_file *seq) > +{ > +#define K(x) ((x) << 10) > + > + struct mem_cgroup *mem_cont = mem_cgroup_from_cont(cgrp); > + struct mcs_total_stat mystat = { }; > + unsigned long long limit, memsw_limit; > + > + mem_cgroup_get_local_stat(mem_cont, &mystat); > + memcg_get_hierarchical_limit(mem_cont, &limit, &memsw_limit); > + > + seq_printf(seq, > + "MemTotal: %8llu kB\n" > + "MemFree: %8llu kB\n", > + limit / 1024, (limit - mystat.stat[MCS_RSS]) / 1024); > + > + return 0; > +#undef K > +} > + > static struct cftype mem_cgroup_files[] = { > { > .name = "usage_in_bytes", > @@ -2242,6 +2263,10 @@ static struct cftype mem_cgroup_files[] > .read_u64 = mem_cgroup_swappiness_read, > .write_u64 = mem_cgroup_swappiness_write, > }, > + { > + .name = "meminfo", > + .read_seq_string = mem_cgroup_meminfo, > + }, > }; > > #ifdef CONFIG_CGROUP_MEM_RES_CTLR_SWAP > > > With the lxc tools I did: > > lxc-execute -n foo /bin/bash > echo 268435456 > /cgroup/foo/memory.limit_in_bytes > mount --bind /cgroup/foo/memory.meminfo /proc/meminfo > for i in $(seq 1 100); do sleep 3600 & done > > And the result for "free" is: > > free: > > total used free shared buffers cached > Mem: 262144 9692 252452 0 0 0 > -/+ buffers/cache: 9692 252452 > Swap: 0 0 0 > > > and for "top": > > top - 22:57:37 up 8 min, 1 user, load average: 0.00, 0.02, 0.00 > Tasks: 104 total, 1 running, 103 sleeping, 0 stopped, 0 zombie > Cpu(s): 0.3%us, 1.0%sy, 0.0%ni, 98.4%id, 0.0%wa, 0.0%hi, 0.3%si, > 0.0%st > Mem: 262144k total, 9864k used, 252280k free, 0k buffers > Swap: 0k total, 0k used, 0k free, 0k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 337 root 20 0 14748 1132 872 R 1.0 0.4 0:00.24 top > 1 root 20 0 8136 484 408 S 0.0 0.2 0:00.00 lxc-init > 2 root 20 0 89980 1724 1348 S 0.0 0.7 0:00.70 bash > 25 root 20 0 86916 612 524 S 0.0 0.2 0:00.00 sleep > 232 root 20 0 86916 616 524 S 0.0 0.2 0:00.00 sleep > 233 root 20 0 86916 612 524 S 0.0 0.2 0:00.00 sleep > 234 root 20 0 86916 612 524 S 0.0 0.2 0:00.00 sleep > 235 root 20 0 86916 612 524 S 0.0 0.2 0:00.00 sleep > ..... > > > :) > > ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <ac1c4bf20908231412m634fdf9h686f6bd24eb95a14-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <ac1c4bf20908231412m634fdf9h686f6bd24eb95a14-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2009-08-24 0:27 ` KAMEZAWA Hiroyuki [not found] ` <20090824092739.70d56a5b.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 0 siblings, 1 reply; 43+ messages in thread From: KAMEZAWA Hiroyuki @ 2009-08-24 0:27 UTC (permalink / raw) To: kt-S89nZTSLPHGGdvJs77BJ7Q Cc: Linux Containers, Krzysztof Taraszka, balbir-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f On Sun, 23 Aug 2009 23:12:24 +0200 Krzysztof Taraszka <krzysztof.taraszka-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org> wrote: > :) excelent :) > > my ugly patch printing right now undefinied data but the idea was the same > :) > how about memsw_limit for swap? :> > I am looking for swap usage statistics from cgroup right now from > memcontrol.c :) but as you did the idea is good and should be add to the > kernel and lxc-tools :) > Hmm, why meminfo is necessary ? For cheating top/free/... etc ? Thanks, -Kame > > 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> > > > Krzysztof Taraszka wrote: > > > >> 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> > >> > >> Krzysztof Taraszka wrote: > >>> > >>> 2009/8/23 Krzysztof Taraszka <krzysztof.taraszka-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org> > >>>> > >>>> > >>>> > >>>> 2009/8/23 Krzysztof Taraszka <krzysztof.taraszka-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org> > >>>>> > >>>>> > >>>>> > >>>>> 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> > >>>>>> > >>>>>> > >>>>>> > >>>>>> Krzysztof Taraszka wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> > >>>>>>>> > >>>>>>>> Krzysztof Taraszka wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> Hello, > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> I am running lxc on my debian unstable sandbox and I have a few > >>>>>>>>>> question > >>>>>>>>>> about memory managament inside linux containers based on lxc > >>>>>>>>>> project. > >>>>>>>>>> > >>>>>>>>>> I have got linux kernel 2.6.30.5 with enabled : > >>>>>>>>>> > >>>>>>>>>> +Resource counter > >>>>>>>>>> ++ Memory Resource Controller for Control Groups > >>>>>>>>>> +++ Memory Resource Controller Swap Extension(EXPERIMENTAL) > >>>>>>>>>> > >>>>>>>>>> lxc-checkconfig pass all checks. > >>>>>>>>>> > >>>>>>>>>> I read about cgroups memory managament > >>>>>>>>>> (Documentation/cgroups/memory.txt) > >>>>>>>>>> and I tried to pass those value to my debian sandbox. > >>>>>>>>>> > >>>>>>>>>> And... > >>>>>>>>>> 'free -m' and 'top/htop' still show all available memory inside > >>>>>>>>>> container > >>>>>>>>>> (also If I set 32M for lxc.cgroup.memory.limit_in_bytes and > >>>>>>>>>> lxc.cgroup.memory.usage_in_bytes; and 64M for > >>>>>>>>>> lxc.cgroup.memory.memsw.usage_in_bytes and > >>>>>>>>>> lxc.cgroup.memory.memsw.limit_in_bytes free and top show all > >>>>>>>>>> resources). > >>>>>>>>>> > >>>>>>>>>> What I did wrong? Does the container always show all available > >>>>>>>>>> memory > >>>>>>>>>> resources without cgroup limitations? > >>>>>>>>>> > >>>>>>>>>> At the first glance I would say the configuration is correct. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> But AFAIR, the memory cgroup is not isolated, if you specify 32MB > >>>>>>>>> you > >>>>>>>>> will > >>>>>>>>> see all the memory available on the system either if you are not > >>>>>>>>> allowed to > >>>>>>>>> use more than 32MB. If you create a program which allocates 64MB > >>>>>>>>> within > >>>>>>>>> a > >>>>>>>>> container configured with 32MB, and you "touch" the pages (may be > >>>>>>>>> that > >>>>>>>>> can > >>>>>>>>> be done with one mmap call with the MAP_POPULATE option), you > >>>>>>>>> should > >>>>>>>>> see the > >>>>>>>>> application swapping and the "memory.failcnt" increasing. > >>>>>>>>> > >>>>>>>>> IMHO, showing all the memory available for the system instead of > >>>>>>>>> showing > >>>>>>>>> the allowed memory with the cgroup is weird but maybe there is a > >>>>>>>>> good > >>>>>>>>> reason > >>>>>>>>> to do that. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Thank you Daniel for your reply. > >>>>>>>> I think that LXC should isolate memory available for containers like > >>>>>>>> Vserver > >>>>>>>> or FreeVPS do (memory + swap) if .cgroup.memory.* and > >>>>>>>> lxc.cgroup.memory.memsw.* is set. > >>>>>>>> Is there any possibility to make a patch for linux kernel / > >>>>>>>> lxc-tools > >>>>>>>> to > >>>>>>>> show the limitations inside cointainers propertly? I think is a good > >>>>>>>> idea > >>>>>>>> and it should be apply as soon as possible. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Maybe a solution can be to add a new memory.meminfo file in the > >>>>>>> same > >>>>>>> format than /proc/meminfo, so it will be possible to mount --bind > >>>>>>> /cgroup/foo/memory.meminfo to /proc/meminfo for the container. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Yes, I thought the same. This should allow the user-space tools > >>>>>> based on > >>>>>> /proc/meminfo (such as comand line "free") show limited information :) > >>>>>> > >>>>>> > >>>>>> > >>>>>> Hmmm... does the memory.stat is a good start point for make new one > >>>>> object > >>>>> memory.meminfo similar to /proc/meminfo? If so, I can play by my self > >>>>> with > >>>>> lxc-tools code. > >>>>> > >>>>> > >>>>> > >>>>> > >>>> Hmmm... Daniel, I have got a question (that do I thinking in the right > >>>> way). > >>>> here is an output from /proc/meminfo from openvz: > >>>> > >>>> > >>>> MemTotal: 262144 kB > >>>> MemFree: 232560 kB > >>>> Buffers: 0 kB > >>>> Cached: 0 kB > >>>> SwapCached: 0 kB > >>>> Active: 0 kB > >>>> Inactive: 0 kB > >>>> HighTotal: 0 kB > >>>> HighFree: 0 kB > >>>> LowTotal: 262144 kB > >>>> LowFree: 232560 kB > >>>> SwapTotal: 0 kB > >>>> SwapFree: 0 kB > >>>> Dirty: 0 kB > >>>> Writeback: 0 kB > >>>> AnonPages: 0 kB > >>>> Mapped: 0 kB > >>>> Slab: 0 kB > >>>> SReclaimable: 0 kB > >>>> SUnreclaim: 0 kB > >>>> PageTables: 0 kB > >>>> NFS_Unstable: 0 kB > >>>> Bounce: 0 kB > >>>> WritebackTmp: 0 kB > >>>> CommitLimit: 0 kB > >>>> Committed_AS: 0 kB > >>>> VmallocTotal: 0 kB > >>>> VmallocUsed: 0 kB > >>>> VmallocChunk: 0 kB > >>>> HugePages_Total: 0 > >>>> HugePages_Free: 0 > >>>> HugePages_Rsvd: 0 > >>>> HugePages_Surp: 0 > >>>> Hugepagesize: 2048 kB > >>>> > >>>> most of values are 0. > >>>> > >>>> I have an question about SwapTotal and SwapFree for LXC. > >>>> As I thinking that: > >>>> > >>>> MemTotal might be: hierarchical_memory_limit > >>>> MemFree might be: hierarchical_memory_limit - cache > >>>> > >>>> > >>>> I am not a memory expert, but isn't MemFree : hierarchical_memory_limit > >>> - > >>> rss ? > >>> > >>> the > >>>> > >>>> SwapTotal might be: hierarchical_memsw_limit > >>>> SwapFree might be: hierarchical_memsw_limit - rss > >>>> > >>>> rss - # of bytes of anonymous and swap cache memory > >>>> I don't know at all that hierarchical_memsw_limit is an good value for > >>>> swap > >>>> total, because as I read it is a mem+swap at all. > >>>> > >>>> Does the lxc memory.meminfo might look like above? Where can I get the > >>>> Hugepagesize? > >>>> > >>>> > >>>> Right, I agree most of the interesting information to create a > >>> memory.meminfo is already there in another file and another format. > >>> Probably > >>> some informations in memory.stat can be moved to memory.meminfo and this > >>> one > >>> can be step by step filled with cgroup memory statistic informations. > >>> IMO, > >>> if the memory controller displays memory statistics like a proc/meminfo > >>> file > >>> format, that will make consistency for these informations and make > >>> trivial > >>> the isolation/virtualization with a simple mount-bind. > >>> > >>> > >>> > >>> Hmm.. > >> might be. Right now I am looking for and writing new function in > >> mm/memcontrol.c file for writing some stats in memory.meminfo file for > >> tests. > >> Dirty and ugly part of code, but if it will work as we thought > >> (mount-bind) > >> and as you wrote above, that will be very simple. > >> I am going to look how does the /proc/meminfo is doing by the openvz. > >> mm/memcontrol.c was wrote by xemul from openvz and balbir from ibm. > >> If I am thinking in the right way, guys from openvz made their own patch > >> for > >> meminfo based on the mm/memcontrol.c. If I am wrong - where do they taking > >> meminfo data? :) > >> > > > > I did this ugly patch patch for MemTotal/MemFree - maybe wrong :) > > > > Index: linux-2.6/mm/memcontrol.c > > =================================================================== > > --- linux-2.6.orig/mm/memcontrol.c 2009-06-23 12:00:52.000000000 +0200 > > +++ linux-2.6/mm/memcontrol.c 2009-08-23 22:49:02.000000000 +0200 > > @@ -2200,6 +2200,27 @@ static int mem_cgroup_swappiness_write(s > > } > > > > > > +static int mem_cgroup_meminfo(struct cgroup *cgrp, struct cftype *cft, > > + struct seq_file *seq) > > +{ > > +#define K(x) ((x) << 10) > > + > > + struct mem_cgroup *mem_cont = mem_cgroup_from_cont(cgrp); > > + struct mcs_total_stat mystat = { }; > > + unsigned long long limit, memsw_limit; > > + > > + mem_cgroup_get_local_stat(mem_cont, &mystat); > > + memcg_get_hierarchical_limit(mem_cont, &limit, &memsw_limit); > > + > > + seq_printf(seq, > > + "MemTotal: %8llu kB\n" > > + "MemFree: %8llu kB\n", > > + limit / 1024, (limit - mystat.stat[MCS_RSS]) / 1024); > > + > > + return 0; > > +#undef K > > +} > > + > > static struct cftype mem_cgroup_files[] = { > > { > > .name = "usage_in_bytes", > > @@ -2242,6 +2263,10 @@ static struct cftype mem_cgroup_files[] > > .read_u64 = mem_cgroup_swappiness_read, > > .write_u64 = mem_cgroup_swappiness_write, > > }, > > + { > > + .name = "meminfo", > > + .read_seq_string = mem_cgroup_meminfo, > > + }, > > }; > > > > #ifdef CONFIG_CGROUP_MEM_RES_CTLR_SWAP > > > > > > With the lxc tools I did: > > > > lxc-execute -n foo /bin/bash > > echo 268435456 > /cgroup/foo/memory.limit_in_bytes > > mount --bind /cgroup/foo/memory.meminfo /proc/meminfo > > for i in $(seq 1 100); do sleep 3600 & done > > > > And the result for "free" is: > > > > free: > > > > total used free shared buffers cached > > Mem: 262144 9692 252452 0 0 0 > > -/+ buffers/cache: 9692 252452 > > Swap: 0 0 0 > > > > > > and for "top": > > > > top - 22:57:37 up 8 min, 1 user, load average: 0.00, 0.02, 0.00 > > Tasks: 104 total, 1 running, 103 sleeping, 0 stopped, 0 zombie > > Cpu(s): 0.3%us, 1.0%sy, 0.0%ni, 98.4%id, 0.0%wa, 0.0%hi, 0.3%si, > > 0.0%st > > Mem: 262144k total, 9864k used, 252280k free, 0k buffers > > Swap: 0k total, 0k used, 0k free, 0k cached > > > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > > 337 root 20 0 14748 1132 872 R 1.0 0.4 0:00.24 top > > 1 root 20 0 8136 484 408 S 0.0 0.2 0:00.00 lxc-init > > 2 root 20 0 89980 1724 1348 S 0.0 0.7 0:00.70 bash > > 25 root 20 0 86916 612 524 S 0.0 0.2 0:00.00 sleep > > 232 root 20 0 86916 616 524 S 0.0 0.2 0:00.00 sleep > > 233 root 20 0 86916 612 524 S 0.0 0.2 0:00.00 sleep > > 234 root 20 0 86916 612 524 S 0.0 0.2 0:00.00 sleep > > 235 root 20 0 86916 612 524 S 0.0 0.2 0:00.00 sleep > > ..... > > > > > > :) > > > > > _______________________________________________ > Containers mailing list > Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org > https://lists.linux-foundation.org/mailman/listinfo/containers > ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <20090824092739.70d56a5b.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <20090824092739.70d56a5b.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> @ 2009-08-24 0:40 ` Krzysztof Taraszka 2009-08-24 6:17 ` [Devel] " Dietmar Maurer 1 sibling, 0 replies; 43+ messages in thread From: Krzysztof Taraszka @ 2009-08-24 0:40 UTC (permalink / raw) To: KAMEZAWA Hiroyuki Cc: Linux Containers, balbir-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f 2009/8/24 KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> > On Sun, 23 Aug 2009 23:12:24 +0200 > Krzysztof Taraszka <krzysztof.taraszka-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org> wrote: > > > :) excelent :) > > > > my ugly patch printing right now undefinied data but the idea was the > same > > :) > > how about memsw_limit for swap? :> > > I am looking for swap usage statistics from cgroup right now from > > memcontrol.c :) but as you did the idea is good and should be add to the > > kernel and lxc-tools :) > > > > Hmm, why meminfo is necessary ? For cheating top/free/... etc ? > > No, but if I am going to limit memory resources of container I would like to see inside this container memory limits when using userspace tools (such as top/free/...) -- Krzysztof Taraszka > > > > 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> > > > > > Krzysztof Taraszka wrote: > > > > > >> 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> > > >> > > >> Krzysztof Taraszka wrote: > > >>> > > >>> 2009/8/23 Krzysztof Taraszka <krzysztof.taraszka-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org> > > >>>> > > >>>> > > >>>> > > >>>> 2009/8/23 Krzysztof Taraszka <krzysztof.taraszka-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org> > > >>>>> > > >>>>> > > >>>>> > > >>>>> 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Krzysztof Taraszka wrote: > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> > > >>>>>>>> > > >>>>>>>> Krzysztof Taraszka wrote: > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> Hello, > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> I am running lxc on my debian unstable sandbox and I have a > few > > >>>>>>>>>> question > > >>>>>>>>>> about memory managament inside linux containers based on lxc > > >>>>>>>>>> project. > > >>>>>>>>>> > > >>>>>>>>>> I have got linux kernel 2.6.30.5 with enabled : > > >>>>>>>>>> > > >>>>>>>>>> +Resource counter > > >>>>>>>>>> ++ Memory Resource Controller for Control Groups > > >>>>>>>>>> +++ Memory Resource Controller Swap Extension(EXPERIMENTAL) > > >>>>>>>>>> > > >>>>>>>>>> lxc-checkconfig pass all checks. > > >>>>>>>>>> > > >>>>>>>>>> I read about cgroups memory managament > > >>>>>>>>>> (Documentation/cgroups/memory.txt) > > >>>>>>>>>> and I tried to pass those value to my debian sandbox. > > >>>>>>>>>> > > >>>>>>>>>> And... > > >>>>>>>>>> 'free -m' and 'top/htop' still show all available memory > inside > > >>>>>>>>>> container > > >>>>>>>>>> (also If I set 32M for lxc.cgroup.memory.limit_in_bytes and > > >>>>>>>>>> lxc.cgroup.memory.usage_in_bytes; and 64M for > > >>>>>>>>>> lxc.cgroup.memory.memsw.usage_in_bytes and > > >>>>>>>>>> lxc.cgroup.memory.memsw.limit_in_bytes free and top show all > > >>>>>>>>>> resources). > > >>>>>>>>>> > > >>>>>>>>>> What I did wrong? Does the container always show all available > > >>>>>>>>>> memory > > >>>>>>>>>> resources without cgroup limitations? > > >>>>>>>>>> > > >>>>>>>>>> At the first glance I would say the configuration is correct. > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> But AFAIR, the memory cgroup is not isolated, if you specify > 32MB > > >>>>>>>>> you > > >>>>>>>>> will > > >>>>>>>>> see all the memory available on the system either if you are > not > > >>>>>>>>> allowed to > > >>>>>>>>> use more than 32MB. If you create a program which allocates > 64MB > > >>>>>>>>> within > > >>>>>>>>> a > > >>>>>>>>> container configured with 32MB, and you "touch" the pages (may > be > > >>>>>>>>> that > > >>>>>>>>> can > > >>>>>>>>> be done with one mmap call with the MAP_POPULATE option), you > > >>>>>>>>> should > > >>>>>>>>> see the > > >>>>>>>>> application swapping and the "memory.failcnt" increasing. > > >>>>>>>>> > > >>>>>>>>> IMHO, showing all the memory available for the system instead > of > > >>>>>>>>> showing > > >>>>>>>>> the allowed memory with the cgroup is weird but maybe there is > a > > >>>>>>>>> good > > >>>>>>>>> reason > > >>>>>>>>> to do that. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> Thank you Daniel for your reply. > > >>>>>>>> I think that LXC should isolate memory available for containers > like > > >>>>>>>> Vserver > > >>>>>>>> or FreeVPS do (memory + swap) if .cgroup.memory.* and > > >>>>>>>> lxc.cgroup.memory.memsw.* is set. > > >>>>>>>> Is there any possibility to make a patch for linux kernel / > > >>>>>>>> lxc-tools > > >>>>>>>> to > > >>>>>>>> show the limitations inside cointainers propertly? I think is a > good > > >>>>>>>> idea > > >>>>>>>> and it should be apply as soon as possible. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> Maybe a solution can be to add a new memory.meminfo file in the > > >>>>>>> same > > >>>>>>> format than /proc/meminfo, so it will be possible to mount --bind > > >>>>>>> /cgroup/foo/memory.meminfo to /proc/meminfo for the container. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> Yes, I thought the same. This should allow the user-space tools > > >>>>>> based on > > >>>>>> /proc/meminfo (such as comand line "free") show limited > information :) > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Hmmm... does the memory.stat is a good start point for make new > one > > >>>>> object > > >>>>> memory.meminfo similar to /proc/meminfo? If so, I can play by my > self > > >>>>> with > > >>>>> lxc-tools code. > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>> Hmmm... Daniel, I have got a question (that do I thinking in the > right > > >>>> way). > > >>>> here is an output from /proc/meminfo from openvz: > > >>>> > > >>>> > > >>>> MemTotal: 262144 kB > > >>>> MemFree: 232560 kB > > >>>> Buffers: 0 kB > > >>>> Cached: 0 kB > > >>>> SwapCached: 0 kB > > >>>> Active: 0 kB > > >>>> Inactive: 0 kB > > >>>> HighTotal: 0 kB > > >>>> HighFree: 0 kB > > >>>> LowTotal: 262144 kB > > >>>> LowFree: 232560 kB > > >>>> SwapTotal: 0 kB > > >>>> SwapFree: 0 kB > > >>>> Dirty: 0 kB > > >>>> Writeback: 0 kB > > >>>> AnonPages: 0 kB > > >>>> Mapped: 0 kB > > >>>> Slab: 0 kB > > >>>> SReclaimable: 0 kB > > >>>> SUnreclaim: 0 kB > > >>>> PageTables: 0 kB > > >>>> NFS_Unstable: 0 kB > > >>>> Bounce: 0 kB > > >>>> WritebackTmp: 0 kB > > >>>> CommitLimit: 0 kB > > >>>> Committed_AS: 0 kB > > >>>> VmallocTotal: 0 kB > > >>>> VmallocUsed: 0 kB > > >>>> VmallocChunk: 0 kB > > >>>> HugePages_Total: 0 > > >>>> HugePages_Free: 0 > > >>>> HugePages_Rsvd: 0 > > >>>> HugePages_Surp: 0 > > >>>> Hugepagesize: 2048 kB > > >>>> > > >>>> most of values are 0. > > >>>> > > >>>> I have an question about SwapTotal and SwapFree for LXC. > > >>>> As I thinking that: > > >>>> > > >>>> MemTotal might be: hierarchical_memory_limit > > >>>> MemFree might be: hierarchical_memory_limit - cache > > >>>> > > >>>> > > >>>> I am not a memory expert, but isn't MemFree : > hierarchical_memory_limit > > >>> - > > >>> rss ? > > >>> > > >>> the > > >>>> > > >>>> SwapTotal might be: hierarchical_memsw_limit > > >>>> SwapFree might be: hierarchical_memsw_limit - rss > > >>>> > > >>>> rss - # of bytes of anonymous and swap cache memory > > >>>> I don't know at all that hierarchical_memsw_limit is an good value > for > > >>>> swap > > >>>> total, because as I read it is a mem+swap at all. > > >>>> > > >>>> Does the lxc memory.meminfo might look like above? Where can I get > the > > >>>> Hugepagesize? > > >>>> > > >>>> > > >>>> Right, I agree most of the interesting information to create a > > >>> memory.meminfo is already there in another file and another format. > > >>> Probably > > >>> some informations in memory.stat can be moved to memory.meminfo and > this > > >>> one > > >>> can be step by step filled with cgroup memory statistic informations. > > >>> IMO, > > >>> if the memory controller displays memory statistics like a > proc/meminfo > > >>> file > > >>> format, that will make consistency for these informations and make > > >>> trivial > > >>> the isolation/virtualization with a simple mount-bind. > > >>> > > >>> > > >>> > > >>> Hmm.. > > >> might be. Right now I am looking for and writing new function in > > >> mm/memcontrol.c file for writing some stats in memory.meminfo file for > > >> tests. > > >> Dirty and ugly part of code, but if it will work as we thought > > >> (mount-bind) > > >> and as you wrote above, that will be very simple. > > >> I am going to look how does the /proc/meminfo is doing by the openvz. > > >> mm/memcontrol.c was wrote by xemul from openvz and balbir from ibm. > > >> If I am thinking in the right way, guys from openvz made their own > patch > > >> for > > >> meminfo based on the mm/memcontrol.c. If I am wrong - where do they > taking > > >> meminfo data? :) > > >> > > > > > > I did this ugly patch patch for MemTotal/MemFree - maybe wrong :) > > > > > > Index: linux-2.6/mm/memcontrol.c > > > =================================================================== > > > --- linux-2.6.orig/mm/memcontrol.c 2009-06-23 12:00:52.000000000 > +0200 > > > +++ linux-2.6/mm/memcontrol.c 2009-08-23 22:49:02.000000000 +0200 > > > @@ -2200,6 +2200,27 @@ static int mem_cgroup_swappiness_write(s > > > } > > > > > > > > > +static int mem_cgroup_meminfo(struct cgroup *cgrp, struct cftype *cft, > > > + struct seq_file *seq) > > > +{ > > > +#define K(x) ((x) << 10) > > > + > > > + struct mem_cgroup *mem_cont = mem_cgroup_from_cont(cgrp); > > > + struct mcs_total_stat mystat = { }; > > > + unsigned long long limit, memsw_limit; > > > + > > > + mem_cgroup_get_local_stat(mem_cont, &mystat); > > > + memcg_get_hierarchical_limit(mem_cont, &limit, &memsw_limit); > > > + > > > + seq_printf(seq, > > > + "MemTotal: %8llu kB\n" > > > + "MemFree: %8llu kB\n", > > > + limit / 1024, (limit - mystat.stat[MCS_RSS]) / > 1024); > > > + > > > + return 0; > > > +#undef K > > > +} > > > + > > > static struct cftype mem_cgroup_files[] = { > > > { > > > .name = "usage_in_bytes", > > > @@ -2242,6 +2263,10 @@ static struct cftype mem_cgroup_files[] > > > .read_u64 = mem_cgroup_swappiness_read, > > > .write_u64 = mem_cgroup_swappiness_write, > > > }, > > > + { > > > + .name = "meminfo", > > > + .read_seq_string = mem_cgroup_meminfo, > > > + }, > > > }; > > > > > > #ifdef CONFIG_CGROUP_MEM_RES_CTLR_SWAP > > > > > > > > > With the lxc tools I did: > > > > > > lxc-execute -n foo /bin/bash > > > echo 268435456 > /cgroup/foo/memory.limit_in_bytes > > > mount --bind /cgroup/foo/memory.meminfo /proc/meminfo > > > for i in $(seq 1 100); do sleep 3600 & done > > > > > > And the result for "free" is: > > > > > > free: > > > > > > total used free shared buffers > cached > > > Mem: 262144 9692 252452 0 0 > 0 > > > -/+ buffers/cache: 9692 252452 > > > Swap: 0 0 0 > > > > > > > > > and for "top": > > > > > > top - 22:57:37 up 8 min, 1 user, load average: 0.00, 0.02, 0.00 > > > Tasks: 104 total, 1 running, 103 sleeping, 0 stopped, 0 zombie > > > Cpu(s): 0.3%us, 1.0%sy, 0.0%ni, 98.4%id, 0.0%wa, 0.0%hi, 0.3%si, > > > 0.0%st > > > Mem: 262144k total, 9864k used, 252280k free, 0k > buffers > > > Swap: 0k total, 0k used, 0k free, 0k cached > > > > > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > > > 337 root 20 0 14748 1132 872 R 1.0 0.4 0:00.24 top > > > 1 root 20 0 8136 484 408 S 0.0 0.2 0:00.00 lxc-init > > > 2 root 20 0 89980 1724 1348 S 0.0 0.7 0:00.70 bash > > > 25 root 20 0 86916 612 524 S 0.0 0.2 0:00.00 sleep > > > 232 root 20 0 86916 616 524 S 0.0 0.2 0:00.00 sleep > > > 233 root 20 0 86916 612 524 S 0.0 0.2 0:00.00 sleep > > > 234 root 20 0 86916 612 524 S 0.0 0.2 0:00.00 sleep > > > 235 root 20 0 86916 612 524 S 0.0 0.2 0:00.00 sleep > > > ..... > > > > > > > > > :) > > > > > > > > _______________________________________________ > > Containers mailing list > > Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org > > https://lists.linux-foundation.org/mailman/listinfo/containers > > > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* RE: [Devel] Re: [lxc-devel] Memory Resources [not found] ` <20090824092739.70d56a5b.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2009-08-24 0:40 ` Krzysztof Taraszka @ 2009-08-24 6:17 ` Dietmar Maurer [not found] ` <90D306BE6EBC8D428A824FBBA7A3113DE076E221-jRgWbcutxcWenyD9vqZGNUEOCMrvLtNR@public.gmane.org> 1 sibling, 1 reply; 43+ messages in thread From: Dietmar Maurer @ 2009-08-24 6:17 UTC (permalink / raw) To: KAMEZAWA Hiroyuki, kt-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org Cc: Linux Containers, Krzysztof Taraszka, balbir-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > > how about memsw_limit for swap? :> > > I am looking for swap usage statistics from cgroup right now from > > memcontrol.c :) but as you did the idea is good and should be add to > the > > kernel and lxc-tools :) > > > > Hmm, why meminfo is necessary ? For cheating top/free/... etc ? Many servers use that info to control the use of resources. For example, they do not span any more server processes if memory is low. If you do not have that info correct, all those programs fails (they try to allocate much more resources than available). - Dietmar ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <90D306BE6EBC8D428A824FBBA7A3113DE076E221-jRgWbcutxcWenyD9vqZGNUEOCMrvLtNR@public.gmane.org>]
* Re: [Devel] Re: [lxc-devel] Memory Resources [not found] ` <90D306BE6EBC8D428A824FBBA7A3113DE076E221-jRgWbcutxcWenyD9vqZGNUEOCMrvLtNR@public.gmane.org> @ 2009-08-24 6:58 ` KAMEZAWA Hiroyuki [not found] ` <20090824155835.94f6b88f.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 0 siblings, 1 reply; 43+ messages in thread From: KAMEZAWA Hiroyuki @ 2009-08-24 6:58 UTC (permalink / raw) To: Dietmar Maurer Cc: Linux Containers, kt-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org, balbir-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org, Krzysztof Taraszka, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org On Mon, 24 Aug 2009 08:17:06 +0200 Dietmar Maurer <dietmar-YTcQvvOqK21BDgjK7y7TUQ@public.gmane.org> wrote: > > > how about memsw_limit for swap? :> > > > I am looking for swap usage statistics from cgroup right now from > > > memcontrol.c :) but as you did the idea is good and should be add to > > the > > > kernel and lxc-tools :) > > > > > > > Hmm, why meminfo is necessary ? For cheating top/free/... etc ? > > Many servers use that info to control the use of resources. For example, they do not span any more server processes if memory is low. > > If you do not have that info correct, all those programs fails (they try to allocate much more resources than available). > Hm, duplicating information for keeping binary compatibility for apps ? What other stat does ? For example, - load average - cpu usage %user, %sys, %iowait, etc.. - fork-per-sec One difficulty I think of is that memcg's limit-usage doesn't means "free". But, hmm, showing "meminfo" in popular/user-friendly format is not very bad. Balbir, how do you think ? If you write a patch, plz onto the newest mmotm. *And*, now, Nishimura-san is posting "show # of swap usage directly" patch. It will be a help for you. Thanks, -Kame ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <20090824155835.94f6b88f.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>]
* Re: [Devel] Re: [lxc-devel] Memory Resources [not found] ` <20090824155835.94f6b88f.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> @ 2009-08-24 7:17 ` Balbir Singh [not found] ` <20090824071757.GQ29572-SINUvgVNF2CyUtPGxGje5AC/G2K4zDHf@public.gmane.org> 0 siblings, 1 reply; 43+ messages in thread From: Balbir Singh @ 2009-08-24 7:17 UTC (permalink / raw) To: KAMEZAWA Hiroyuki Cc: Linux Containers, kt-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org, Dietmar Maurer, Krzysztof Taraszka, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org * KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> [2009-08-24 15:58:35]: > On Mon, 24 Aug 2009 08:17:06 +0200 > Dietmar Maurer <dietmar-YTcQvvOqK21BDgjK7y7TUQ@public.gmane.org> wrote: > > > > > how about memsw_limit for swap? :> > > > > I am looking for swap usage statistics from cgroup right now from > > > > memcontrol.c :) but as you did the idea is good and should be add to > > > the > > > > kernel and lxc-tools :) > > > > > > > > > > Hmm, why meminfo is necessary ? For cheating top/free/... etc ? > > > > Many servers use that info to control the use of resources. For example, they do not span any more server processes if memory is low. > > > > If you do not have that info correct, all those programs fails (they try to allocate much more resources than available). > > > > Hm, duplicating information for keeping binary compatibility for apps ? > What other stat does ? > For example, > - load average > - cpu usage %user, %sys, %iowait, etc.. > - fork-per-sec > > One difficulty I think of is that memcg's limit-usage doesn't means "free". > But, hmm, showing "meminfo" in popular/user-friendly format is not very bad. > Balbir, how do you think ? > Sorry, I've missed the context and unable to follow the discussion. IIUC, the request is to show per-container statistics? > If you write a patch, plz onto the newest mmotm. > *And*, now, Nishimura-san is posting "show # of swap usage directly" patch. > It will be a help for you. -- Balbir ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <20090824071757.GQ29572-SINUvgVNF2CyUtPGxGje5AC/G2K4zDHf@public.gmane.org>]
* Re: [Devel] Re: [lxc-devel] Memory Resources [not found] ` <20090824071757.GQ29572-SINUvgVNF2CyUtPGxGje5AC/G2K4zDHf@public.gmane.org> @ 2009-08-24 7:18 ` KAMEZAWA Hiroyuki [not found] ` <20090824161825.c40a85a2.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 0 siblings, 1 reply; 43+ messages in thread From: KAMEZAWA Hiroyuki @ 2009-08-24 7:18 UTC (permalink / raw) To: balbir-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8 Cc: Linux Containers, kt-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org, Dietmar Maurer, Krzysztof Taraszka, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org On Mon, 24 Aug 2009 12:47:57 +0530 Balbir Singh <balbir-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> wrote: > * KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> [2009-08-24 15:58:35]: > > > On Mon, 24 Aug 2009 08:17:06 +0200 > > Dietmar Maurer <dietmar-YTcQvvOqK21BDgjK7y7TUQ@public.gmane.org> wrote: > > > > > > > how about memsw_limit for swap? :> > > > > > I am looking for swap usage statistics from cgroup right now from > > > > > memcontrol.c :) but as you did the idea is good and should be add to > > > > the > > > > > kernel and lxc-tools :) > > > > > > > > > > > > > Hmm, why meminfo is necessary ? For cheating top/free/... etc ? > > > > > > Many servers use that info to control the use of resources. For example, they do not span any more server processes if memory is low. > > > > > > If you do not have that info correct, all those programs fails (they try to allocate much more resources than available). > > > > > > > Hm, duplicating information for keeping binary compatibility for apps ? > > What other stat does ? > > For example, > > - load average > > - cpu usage %user, %sys, %iowait, etc.. > > - fork-per-sec > > > > One difficulty I think of is that memcg's limit-usage doesn't means "free". > > But, hmm, showing "meminfo" in popular/user-friendly format is not very bad. > > Balbir, how do you think ? > > > > Sorry, I've missed the context and unable to follow the discussion. > IIUC, the request is to show per-container statistics? > per-container "meminfo" i.e. the same format information as "meminfo". (Then, duplicating information of memory.stat") Thanks, -Kame ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <20090824161825.c40a85a2.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>]
* Re: [Devel] Re: [lxc-devel] Memory Resources [not found] ` <20090824161825.c40a85a2.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> @ 2009-08-25 9:46 ` Balbir Singh 0 siblings, 0 replies; 43+ messages in thread From: Balbir Singh @ 2009-08-25 9:46 UTC (permalink / raw) To: KAMEZAWA Hiroyuki Cc: Linux Containers, kt-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org, Dietmar Maurer, Krzysztof Taraszka, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org * KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> [2009-08-24 16:18:25]: > On Mon, 24 Aug 2009 12:47:57 +0530 > Balbir Singh <balbir-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> wrote: > > > * KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> [2009-08-24 15:58:35]: > > > > > On Mon, 24 Aug 2009 08:17:06 +0200 > > > Dietmar Maurer <dietmar-YTcQvvOqK21BDgjK7y7TUQ@public.gmane.org> wrote: > > > > > > > > > how about memsw_limit for swap? :> > > > > > > I am looking for swap usage statistics from cgroup right now from > > > > > > memcontrol.c :) but as you did the idea is good and should be add to > > > > > the > > > > > > kernel and lxc-tools :) > > > > > > > > > > > > > > > > Hmm, why meminfo is necessary ? For cheating top/free/... etc ? > > > > > > > > Many servers use that info to control the use of resources. For example, they do not span any more server processes if memory is low. > > > > > > > > If you do not have that info correct, all those programs fails (they try to allocate much more resources than available). > > > > > > > > > > Hm, duplicating information for keeping binary compatibility for apps ? > > > What other stat does ? > > > For example, > > > - load average > > > - cpu usage %user, %sys, %iowait, etc.. > > > - fork-per-sec > > > > > > One difficulty I think of is that memcg's limit-usage doesn't means "free". > > > But, hmm, showing "meminfo" in popular/user-friendly format is not very bad. > > > Balbir, how do you think ? > > > > > > > Sorry, I've missed the context and unable to follow the discussion. > > IIUC, the request is to show per-container statistics? > > > per-container "meminfo" i.e. the same format information as "meminfo". > (Then, duplicating information of memory.stat") That seems like a reasonable goal to achieve. -- Balbir ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [lxc-devel] Memory Resources [not found] ` <4A91ADE1.9090204-GANU6spQydw@public.gmane.org> 2009-08-23 21:12 ` Krzysztof Taraszka @ 2009-08-24 0:48 ` Krzysztof Taraszka 2009-08-24 0:58 ` Krzysztof Taraszka 2 siblings, 0 replies; 43+ messages in thread From: Krzysztof Taraszka @ 2009-08-24 0:48 UTC (permalink / raw) To: Daniel Lezcano Cc: Linux Containers, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f I added the swap resource monitoring to your patch. I did it in the very simple way, because if: memsw = swap + mem, then swap_in_use == memsw.usage_in_bytes - memory.usage_in_bytes simple patch: +static int mem_cgroup_meminfo(struct cgroup *cgrp, struct cftype *cft, + struct seq_file *seq) +{ +#define K(x) ((x) << 10) + + struct mem_cgroup *mem_cont = mem_cgroup_from_cont(cgrp); + struct mcs_total_stat mystat = { }; + unsigned long long limit, memsw_limit; + + u64 swap_in_u, m_usage, s_usage; + + s_usage = res_counter_read_u64(&mem_cont->memsw, RES_USAGE); + m_usage = res_counter_read_u64(&mem_cont->res, RES_USAGE); + + swap_in_u = s_usage - m_usage; + + mem_cgroup_get_local_stat(mem_cont, &mystat); + memcg_get_hierarchical_limit(mem_cont, &limit, &memsw_limit); + + seq_printf(seq, + "MemTotal: %8llu kB\n" + "MemFree: %8llu kB\n" + "SwapTotal: %8llu kB\n" + "SwapFree: %8llu kB\n", + limit / 1024, (limit - mystat.stat[MCS_RSS]) / 1024, + memsw_limit / 1024, (memsw_limit - swap_in_u) / 1024); + + return 0; +#undef K +} static struct cftype mem_cgroup_files[] = { { @@ -2228,6 +2258,10 @@ .name = "stat", .read_map = mem_control_stat_show, }, + { + .name = "meminfo", + .read_seq_string = mem_cgroup_meminfo, + }, { .name = "force_empty", .trigger = mem_cgroup_force_empty_write, -- Krzysztof Taraszka 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> > Krzysztof Taraszka wrote: > >> 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >> >> Krzysztof Taraszka wrote: >>> >>> 2009/8/23 Krzysztof Taraszka <krzysztof.taraszka-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org> >>>> >>>> >>>> >>>> 2009/8/23 Krzysztof Taraszka <krzysztof.taraszka-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org> >>>>> >>>>> >>>>> >>>>> 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >>>>>> >>>>>> >>>>>> >>>>>> Krzysztof Taraszka wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >>>>>>>> >>>>>>>> Krzysztof Taraszka wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hello, >>>>>>>>> >>>>>>>>> >>>>>>>>> I am running lxc on my debian unstable sandbox and I have a few >>>>>>>>>> question >>>>>>>>>> about memory managament inside linux containers based on lxc >>>>>>>>>> project. >>>>>>>>>> >>>>>>>>>> I have got linux kernel 2.6.30.5 with enabled : >>>>>>>>>> >>>>>>>>>> +Resource counter >>>>>>>>>> ++ Memory Resource Controller for Control Groups >>>>>>>>>> +++ Memory Resource Controller Swap Extension(EXPERIMENTAL) >>>>>>>>>> >>>>>>>>>> lxc-checkconfig pass all checks. >>>>>>>>>> >>>>>>>>>> I read about cgroups memory managament >>>>>>>>>> (Documentation/cgroups/memory.txt) >>>>>>>>>> and I tried to pass those value to my debian sandbox. >>>>>>>>>> >>>>>>>>>> And... >>>>>>>>>> 'free -m' and 'top/htop' still show all available memory inside >>>>>>>>>> container >>>>>>>>>> (also If I set 32M for lxc.cgroup.memory.limit_in_bytes and >>>>>>>>>> lxc.cgroup.memory.usage_in_bytes; and 64M for >>>>>>>>>> lxc.cgroup.memory.memsw.usage_in_bytes and >>>>>>>>>> lxc.cgroup.memory.memsw.limit_in_bytes free and top show all >>>>>>>>>> resources). >>>>>>>>>> >>>>>>>>>> What I did wrong? Does the container always show all available >>>>>>>>>> memory >>>>>>>>>> resources without cgroup limitations? >>>>>>>>>> >>>>>>>>>> At the first glance I would say the configuration is correct. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> But AFAIR, the memory cgroup is not isolated, if you specify 32MB >>>>>>>>> you >>>>>>>>> will >>>>>>>>> see all the memory available on the system either if you are not >>>>>>>>> allowed to >>>>>>>>> use more than 32MB. If you create a program which allocates 64MB >>>>>>>>> within >>>>>>>>> a >>>>>>>>> container configured with 32MB, and you "touch" the pages (may be >>>>>>>>> that >>>>>>>>> can >>>>>>>>> be done with one mmap call with the MAP_POPULATE option), you >>>>>>>>> should >>>>>>>>> see the >>>>>>>>> application swapping and the "memory.failcnt" increasing. >>>>>>>>> >>>>>>>>> IMHO, showing all the memory available for the system instead of >>>>>>>>> showing >>>>>>>>> the allowed memory with the cgroup is weird but maybe there is a >>>>>>>>> good >>>>>>>>> reason >>>>>>>>> to do that. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thank you Daniel for your reply. >>>>>>>> I think that LXC should isolate memory available for containers like >>>>>>>> Vserver >>>>>>>> or FreeVPS do (memory + swap) if .cgroup.memory.* and >>>>>>>> lxc.cgroup.memory.memsw.* is set. >>>>>>>> Is there any possibility to make a patch for linux kernel / >>>>>>>> lxc-tools >>>>>>>> to >>>>>>>> show the limitations inside cointainers propertly? I think is a good >>>>>>>> idea >>>>>>>> and it should be apply as soon as possible. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Maybe a solution can be to add a new memory.meminfo file in the >>>>>>> same >>>>>>> format than /proc/meminfo, so it will be possible to mount --bind >>>>>>> /cgroup/foo/memory.meminfo to /proc/meminfo for the container. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Yes, I thought the same. This should allow the user-space tools >>>>>> based on >>>>>> /proc/meminfo (such as comand line "free") show limited information :) >>>>>> >>>>>> >>>>>> >>>>>> Hmmm... does the memory.stat is a good start point for make new one >>>>> object >>>>> memory.meminfo similar to /proc/meminfo? If so, I can play by my self >>>>> with >>>>> lxc-tools code. >>>>> >>>>> >>>>> >>>>> >>>> Hmmm... Daniel, I have got a question (that do I thinking in the right >>>> way). >>>> here is an output from /proc/meminfo from openvz: >>>> >>>> >>>> MemTotal: 262144 kB >>>> MemFree: 232560 kB >>>> Buffers: 0 kB >>>> Cached: 0 kB >>>> SwapCached: 0 kB >>>> Active: 0 kB >>>> Inactive: 0 kB >>>> HighTotal: 0 kB >>>> HighFree: 0 kB >>>> LowTotal: 262144 kB >>>> LowFree: 232560 kB >>>> SwapTotal: 0 kB >>>> SwapFree: 0 kB >>>> Dirty: 0 kB >>>> Writeback: 0 kB >>>> AnonPages: 0 kB >>>> Mapped: 0 kB >>>> Slab: 0 kB >>>> SReclaimable: 0 kB >>>> SUnreclaim: 0 kB >>>> PageTables: 0 kB >>>> NFS_Unstable: 0 kB >>>> Bounce: 0 kB >>>> WritebackTmp: 0 kB >>>> CommitLimit: 0 kB >>>> Committed_AS: 0 kB >>>> VmallocTotal: 0 kB >>>> VmallocUsed: 0 kB >>>> VmallocChunk: 0 kB >>>> HugePages_Total: 0 >>>> HugePages_Free: 0 >>>> HugePages_Rsvd: 0 >>>> HugePages_Surp: 0 >>>> Hugepagesize: 2048 kB >>>> >>>> most of values are 0. >>>> >>>> I have an question about SwapTotal and SwapFree for LXC. >>>> As I thinking that: >>>> >>>> MemTotal might be: hierarchical_memory_limit >>>> MemFree might be: hierarchical_memory_limit - cache >>>> >>>> >>>> I am not a memory expert, but isn't MemFree : hierarchical_memory_limit >>> - >>> rss ? >>> >>> the >>>> >>>> SwapTotal might be: hierarchical_memsw_limit >>>> SwapFree might be: hierarchical_memsw_limit - rss >>>> >>>> rss - # of bytes of anonymous and swap cache memory >>>> I don't know at all that hierarchical_memsw_limit is an good value for >>>> swap >>>> total, because as I read it is a mem+swap at all. >>>> >>>> Does the lxc memory.meminfo might look like above? Where can I get the >>>> Hugepagesize? >>>> >>>> >>>> Right, I agree most of the interesting information to create a >>> memory.meminfo is already there in another file and another format. >>> Probably >>> some informations in memory.stat can be moved to memory.meminfo and this >>> one >>> can be step by step filled with cgroup memory statistic informations. >>> IMO, >>> if the memory controller displays memory statistics like a proc/meminfo >>> file >>> format, that will make consistency for these informations and make >>> trivial >>> the isolation/virtualization with a simple mount-bind. >>> >>> >>> >>> Hmm.. >> might be. Right now I am looking for and writing new function in >> mm/memcontrol.c file for writing some stats in memory.meminfo file for >> tests. >> Dirty and ugly part of code, but if it will work as we thought >> (mount-bind) >> and as you wrote above, that will be very simple. >> I am going to look how does the /proc/meminfo is doing by the openvz. >> mm/memcontrol.c was wrote by xemul from openvz and balbir from ibm. >> If I am thinking in the right way, guys from openvz made their own patch >> for >> meminfo based on the mm/memcontrol.c. If I am wrong - where do they taking >> meminfo data? :) >> > > I did this ugly patch patch for MemTotal/MemFree - maybe wrong :) > > Index: linux-2.6/mm/memcontrol.c > =================================================================== > --- linux-2.6.orig/mm/memcontrol.c 2009-06-23 12:00:52.000000000 +0200 > +++ linux-2.6/mm/memcontrol.c 2009-08-23 22:49:02.000000000 +0200 > @@ -2200,6 +2200,27 @@ static int mem_cgroup_swappiness_write(s > } > > > +static int mem_cgroup_meminfo(struct cgroup *cgrp, struct cftype *cft, > + struct seq_file *seq) > +{ > +#define K(x) ((x) << 10) > + > + struct mem_cgroup *mem_cont = mem_cgroup_from_cont(cgrp); > + struct mcs_total_stat mystat = { }; > + unsigned long long limit, memsw_limit; > + > + mem_cgroup_get_local_stat(mem_cont, &mystat); > + memcg_get_hierarchical_limit(mem_cont, &limit, &memsw_limit); > + > + seq_printf(seq, > + "MemTotal: %8llu kB\n" > + "MemFree: %8llu kB\n", > + limit / 1024, (limit - mystat.stat[MCS_RSS]) / 1024); > + > + return 0; > +#undef K > +} > + > static struct cftype mem_cgroup_files[] = { > { > .name = "usage_in_bytes", > @@ -2242,6 +2263,10 @@ static struct cftype mem_cgroup_files[] > .read_u64 = mem_cgroup_swappiness_read, > .write_u64 = mem_cgroup_swappiness_write, > }, > + { > + .name = "meminfo", > + .read_seq_string = mem_cgroup_meminfo, > + }, > }; > > #ifdef CONFIG_CGROUP_MEM_RES_CTLR_SWAP > > > With the lxc tools I did: > > lxc-execute -n foo /bin/bash > echo 268435456 > /cgroup/foo/memory.limit_in_bytes > mount --bind /cgroup/foo/memory.meminfo /proc/meminfo > for i in $(seq 1 100); do sleep 3600 & done > > And the result for "free" is: > > free: > > total used free shared buffers cached > Mem: 262144 9692 252452 0 0 0 > -/+ buffers/cache: 9692 252452 > Swap: 0 0 0 > > > and for "top": > > top - 22:57:37 up 8 min, 1 user, load average: 0.00, 0.02, 0.00 > Tasks: 104 total, 1 running, 103 sleeping, 0 stopped, 0 zombie > Cpu(s): 0.3%us, 1.0%sy, 0.0%ni, 98.4%id, 0.0%wa, 0.0%hi, 0.3%si, > 0.0%st > Mem: 262144k total, 9864k used, 252280k free, 0k buffers > Swap: 0k total, 0k used, 0k free, 0k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 337 root 20 0 14748 1132 872 R 1.0 0.4 0:00.24 top > 1 root 20 0 8136 484 408 S 0.0 0.2 0:00.00 lxc-init > 2 root 20 0 89980 1724 1348 S 0.0 0.7 0:00.70 bash > 25 root 20 0 86916 612 524 S 0.0 0.2 0:00.00 sleep > 232 root 20 0 86916 616 524 S 0.0 0.2 0:00.00 sleep > 233 root 20 0 86916 612 524 S 0.0 0.2 0:00.00 sleep > 234 root 20 0 86916 612 524 S 0.0 0.2 0:00.00 sleep > 235 root 20 0 86916 612 524 S 0.0 0.2 0:00.00 sleep > ..... > > > :) > > ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [lxc-devel] Memory Resources [not found] ` <4A91ADE1.9090204-GANU6spQydw@public.gmane.org> 2009-08-23 21:12 ` Krzysztof Taraszka 2009-08-24 0:48 ` Krzysztof Taraszka @ 2009-08-24 0:58 ` Krzysztof Taraszka [not found] ` <4A924D11.80002@free.fr> 2 siblings, 1 reply; 43+ messages in thread From: Krzysztof Taraszka @ 2009-08-24 0:58 UTC (permalink / raw) To: Daniel Lezcano Cc: Linux Containers, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> (...) > With the lxc tools I did: > > lxc-execute -n foo /bin/bash > echo 268435456 > /cgroup/foo/memory.limit_in_bytes > mount --bind /cgroup/foo/memory.meminfo /proc/meminfo > for i in $(seq 1 100); do sleep 3600 & done (...) > > :) > > hmmm... I think that access to the cgroup inside container is very risk because I am able to manage for example memory resources (what if I am not the host owner and... I can give me via non-secure mounted /cgroup (inside container) all available memory resources...). I think that the /proc/meminfo should be pass to the container in the other way, but this is the topic for the other thread. ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <4A924D11.80002@free.fr>]
[parent not found: <ac1c4bf20908240125q1e126cdq2d2b7659ca167d52@mail.gmail.com>]
[parent not found: <4A924F5C.1000208@fr.ibm.com>]
[parent not found: <ac1c4bf20908240138l67cfabfcid2bb7224a1f6ab24@mail.gmail.com>]
[parent not found: <4A925794.7050808@free.fr>]
[parent not found: <ac1c4bf20908240245ydbc1b9bxacfcf2398049505c@mail.gmail.com>]
[parent not found: <4A92676A.1080609@free.fr>]
[parent not found: <4A92676A.1080609-GANU6spQydw@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <4A92676A.1080609-GANU6spQydw@public.gmane.org> @ 2009-08-24 10:58 ` Krzysztof Taraszka 0 siblings, 0 replies; 43+ messages in thread From: Krzysztof Taraszka @ 2009-08-24 10:58 UTC (permalink / raw) To: Daniel Lezcano Cc: Linux Containers, Daniel Lezcano, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f 2009/8/24 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> > Krzysztof Taraszka wrote: > >> 2009/8/24 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >> >> >> >>> Krzysztof Taraszka wrote: >>> >>> >>> >>>> 2009/8/24 Daniel Lezcano <dlezcano-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org> >>>> >>>> >>>> >>>> >>>> >>>>> Krzysztof Taraszka wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> 2009/8/24 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >>>>>> >>>>>> Krzysztof Taraszka wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> (...) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> With the lxc tools I did: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> lxc-execute -n foo /bin/bash >>>>>>>>> echo 268435456 > /cgroup/foo/memory.limit_in_bytes >>>>>>>>> mount --bind /cgroup/foo/memory.meminfo /proc/meminfo >>>>>>>>> for i in $(seq 1 100); do sleep 3600 & done >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> (...) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> :) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> hmmm... I think that access to the cgroup inside container is very >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> risk >>>>>>>> because I am able to manage for example memory resources (what if I >>>>>>>> am >>>>>>>> not >>>>>>>> the host owner and... I can give me via non-secure mounted /cgroup >>>>>>>> (inside >>>>>>>> container) all available memory resources...). >>>>>>>> I think that the /proc/meminfo should be pass to the container in >>>>>>>> the >>>>>>>> other >>>>>>>> way, but this is the topic for the other thread. >>>>>>>> >>>>>>>> >>>>>>>> It is not a problem, I did it in this way because it's easy to test >>>>>>>> but >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> in >>>>>>> a real use case, the memory limit is setup by the lxc configuration >>>>>>> file >>>>>>> and >>>>>>> the cgroup directory will be no longer accessible from the container. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> So.. how there will be another method (more secure) for giving >>>>>> /proc/meminfo >>>>>> with limits to the container, right? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Same method. The lxc tools can be configured with a fstab to mount more >>>>> mount points, furthermore if memory.meminfo is available I will add the >>>>> code >>>>> to mount it automatically to /proc/meminfo in the lxc tools. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> Hmm... setup_fs() from lxc_init.c or another way? >>>> >>>> >>>> >>>> >>> No, I was thinking in the setup_cgroup() function in conf.c. >>> >>> Something like: >>> >>> ... >>> >>> if (!access("/var/lib/lxc/mycontainer/nsgroup/memory.meminfo"), F_OK) { >>> mount("/var/lib/lxc/mycontainer/nsgroup/memory.meminfo", >>> "/proc/meminfo", >>> MS_BIND, ...); >>> } >>> >>> ... >>> >>> >>> but a bit more clean :) >>> >>> >>> >> >> >> hmm... ok, got it, but don't know why does it won't work ;) >> >> @@ -999,12 +999,14 @@ >> static int setup_cgroup(const char *name) >> { >> char filename[MAXPATHLEN]; >> + char meminfofilename[MAXPATHLEN]; >> char line[MAXPATHLEN]; >> struct stat s; >> int ret; >> >> snprintf(filename, MAXPATHLEN, LXCPATH "/%s/cgroup", name); >> - >> + snprintf(meminfofilename, MAXPATHLEN, LXCPATH >> "/%s/nsgroup/memory.meminfo", name); >> + >> if (stat(filename, &s)) { >> SYSERROR("failed to stat '%s'", filename); >> return -1; >> @@ -1024,6 +1026,10 @@ >> >> INFO("cgroup has been setup"); >> >> + /* mount memory.meminfo as /proc/meminfo */ >> + if (!access(meminfofilename, F_OK)) { >> + mount(meminfofilename, "/proc/meminfo", "none", MS_BIND, 0); >> + } >> return 0; >> } >> >> >> hmm... any idea Daniel? :) >> >> > Yep, can you check the return code of the mount call and return an error ? > if (mount(....)) { > SYSERROR("failed to mount '%s' to '/proc/meminfo'", meminfofilename); > return -1; > } > at least to verify if this does not fail. > and maybe add an INFO trace if the mount is successful saying > "/proc/meminfo" is setup with the cgroup. > > ps : you should launch the command with the "-l INFO" to see the message. > Weird. I made a test and move the mount the /proc/meminfo to the setup_console() and it did not take effect. mount() did not fail (there were no failed log). Why I moved this part of code? Well.. I was wonder that what was happend if I mount /proc/meminfo after the setup_mount() to override /proc/meminfo. Don't have idea what can I do next ;) Daniel? -- Krzysztof Taraszka ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <ac1c4bf20908240327u424bd021t8848cf1cafb24ada@mail.gmail.com>]
[parent not found: <ac1c4bf20908240327u424bd021t8848cf1cafb24ada-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <ac1c4bf20908240327u424bd021t8848cf1cafb24ada-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2009-08-24 11:13 ` Daniel Lezcano [not found] ` <4A9275CB.7030108-GANU6spQydw@public.gmane.org> 0 siblings, 1 reply; 43+ messages in thread From: Daniel Lezcano @ 2009-08-24 11:13 UTC (permalink / raw) To: kt-S89nZTSLPHGGdvJs77BJ7Q Cc: Linux Containers, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Krzysztof Taraszka wrote: > 2009/8/24 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> > > >> Krzysztof Taraszka wrote: >> >> >>> 2009/8/24 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >>> >>> >>> >>> >>>> Krzysztof Taraszka wrote: >>>> >>>> >>>> >>>> >>>>> 2009/8/24 Daniel Lezcano <dlezcano-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Krzysztof Taraszka wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> 2009/8/24 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >>>>>>> >>>>>>> Krzysztof Taraszka wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> (...) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> With the lxc tools I did: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> lxc-execute -n foo /bin/bash >>>>>>>>>> echo 268435456 > /cgroup/foo/memory.limit_in_bytes >>>>>>>>>> mount --bind /cgroup/foo/memory.meminfo /proc/meminfo >>>>>>>>>> for i in $(seq 1 100); do sleep 3600 & done >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> (...) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> :) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> hmmm... I think that access to the cgroup inside container is very >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> risk >>>>>>>>> because I am able to manage for example memory resources (what if I >>>>>>>>> am >>>>>>>>> not >>>>>>>>> the host owner and... I can give me via non-secure mounted /cgroup >>>>>>>>> (inside >>>>>>>>> container) all available memory resources...). >>>>>>>>> I think that the /proc/meminfo should be pass to the container in >>>>>>>>> the >>>>>>>>> other >>>>>>>>> way, but this is the topic for the other thread. >>>>>>>>> >>>>>>>>> >>>>>>>>> It is not a problem, I did it in this way because it's easy to test >>>>>>>>> but >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> in >>>>>>>> a real use case, the memory limit is setup by the lxc configuration >>>>>>>> file >>>>>>>> and >>>>>>>> the cgroup directory will be no longer accessible from the container. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> So.. how there will be another method (more secure) for giving >>>>>>> /proc/meminfo >>>>>>> with limits to the container, right? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Same method. The lxc tools can be configured with a fstab to mount more >>>>>> mount points, furthermore if memory.meminfo is available I will add the >>>>>> code >>>>>> to mount it automatically to /proc/meminfo in the lxc tools. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Hmm... setup_fs() from lxc_init.c or another way? >>>>> >>>>> >>>>> >>>>> >>>>> >>>> No, I was thinking in the setup_cgroup() function in conf.c. >>>> >>>> Something like: >>>> >>>> ... >>>> >>>> if (!access("/var/lib/lxc/mycontainer/nsgroup/memory.meminfo"), F_OK) { >>>> mount("/var/lib/lxc/mycontainer/nsgroup/memory.meminfo", >>>> "/proc/meminfo", >>>> MS_BIND, ...); >>>> } >>>> >>>> ... >>>> >>>> >>>> but a bit more clean :) >>>> >>>> >>>> >>>> >>> hmm... ok, got it, but don't know why does it won't work ;) >>> >>> @@ -999,12 +999,14 @@ >>> static int setup_cgroup(const char *name) >>> { >>> char filename[MAXPATHLEN]; >>> + char meminfofilename[MAXPATHLEN]; >>> char line[MAXPATHLEN]; >>> struct stat s; >>> int ret; >>> >>> snprintf(filename, MAXPATHLEN, LXCPATH "/%s/cgroup", name); >>> - >>> + snprintf(meminfofilename, MAXPATHLEN, LXCPATH >>> "/%s/nsgroup/memory.meminfo", name); >>> + >>> if (stat(filename, &s)) { >>> SYSERROR("failed to stat '%s'", filename); >>> return -1; >>> @@ -1024,6 +1026,10 @@ >>> >>> INFO("cgroup has been setup"); >>> >>> + /* mount memory.meminfo as /proc/meminfo */ >>> + if (!access(meminfofilename, F_OK)) { >>> + mount(meminfofilename, "/proc/meminfo", "none", MS_BIND, 0); >>> + } >>> return 0; >>> } >>> >>> >>> hmm... any idea Daniel? :) >>> >>> >>> >> Yep, can you check the return code of the mount call and return an error ? >> if (mount(....)) { >> SYSERROR("failed to mount '%s' to '/proc/meminfo'", meminfofilename); >> return -1; >> } >> at least to verify if this does not fail. >> and maybe add an INFO trace if the mount is successful saying >> "/proc/meminfo" is setup with the cgroup. >> >> ps : you should launch the command with the "-l INFO" to see the message. >> >> > > > > > Hmmm.... > i think that I know where the problem might be: > > look here: > > lxc1:~# cat debin.log > lxc-start 1251109397.922 INFO lxc_conf - tty's configured > lxc-start 1251109397.922 INFO lxc_start - 'debian' is initialized > lxc-start 1251109397.974 INFO lxc_conf - 'debian' hostname has > been setup > lxc-start 1251109397.975 INFO lxc_conf - network has been setup > lxc-start 1251109397.976 INFO lxc_conf - cgroup has been setup > lxc-start 1251109397.976 INFO lxc_conf - /proc/meminfo is setup > with the cgroup > lxc-start 1251109397.976 INFO lxc_conf - mount points have been > setup > lxc-start 1251109397.976 INFO lxc_conf - console '/dev/pts/1' > mounted to '/usr/local/var/lib/lxc/debian/rootfs/dev/console' > lxc-start 1251109397.977 INFO lxc_conf - 4 tty(s) has been setup > lxc-start 1251109397.977 INFO lxc_conf - chrooted to > '/usr/local/var/lib/lxc/debian/rootfs' > lxc-start 1251109397.977 INFO lxc_conf - created new pts instance > lxc-start 1251109397.977 NOTICE lxc_conf - 'debian' is setup. > lxc-start 1251109397.977 NOTICE lxc_start - exec'ing '/sbin/init' > lxc-start 1251109397.978 NOTICE lxc_start - '/sbin/init' started > with pid '24339' > > i think that /proc/meminfo should be mounted after /proc . why? i think > that, because mounting /proc may override /proc/meminfo > Am I right? :) > Ha ! haha ! arrgh ! no way ! You are right :/ In the case of application container, lxc mounts /proc but in the case of system container it is the system who do that so after the /proc/meminfo has been mounted. Maybe we can look at modifying fs/proc/meminfo.c instead. Let me do a small patch for the kernel... ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <4A9275CB.7030108-GANU6spQydw@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <4A9275CB.7030108-GANU6spQydw@public.gmane.org> @ 2009-08-24 11:31 ` Krzysztof Taraszka [not found] ` <ac1c4bf20908240431p1fda5a15qd26629618397696-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 43+ messages in thread From: Krzysztof Taraszka @ 2009-08-24 11:31 UTC (permalink / raw) To: Daniel Lezcano Cc: Linux Containers, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f 2009/8/24 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> > Krzysztof Taraszka wrote: > >> 2009/8/24 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >> >> >> >>> Krzysztof Taraszka wrote: >>> >>> >>> >>>> 2009/8/24 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >>>> >>>> >>>> >>>> >>>> >>>>> Krzysztof Taraszka wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> 2009/8/24 Daniel Lezcano <dlezcano-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Krzysztof Taraszka wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> 2009/8/24 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >>>>>>>> >>>>>>>> Krzysztof Taraszka wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> 2009/8/23 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> (...) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> With the lxc tools I did: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> lxc-execute -n foo /bin/bash >>>>>>>>>>> echo 268435456 > /cgroup/foo/memory.limit_in_bytes >>>>>>>>>>> mount --bind /cgroup/foo/memory.meminfo /proc/meminfo >>>>>>>>>>> for i in $(seq 1 100); do sleep 3600 & done >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> (...) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> :) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> hmmm... I think that access to the cgroup inside container is >>>>>>>>>>> very >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> risk >>>>>>>>>> because I am able to manage for example memory resources (what if >>>>>>>>>> I >>>>>>>>>> am >>>>>>>>>> not >>>>>>>>>> the host owner and... I can give me via non-secure mounted /cgroup >>>>>>>>>> (inside >>>>>>>>>> container) all available memory resources...). >>>>>>>>>> I think that the /proc/meminfo should be pass to the container in >>>>>>>>>> the >>>>>>>>>> other >>>>>>>>>> way, but this is the topic for the other thread. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It is not a problem, I did it in this way because it's easy to >>>>>>>>>> test >>>>>>>>>> but >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> in >>>>>>>>> a real use case, the memory limit is setup by the lxc configuration >>>>>>>>> file >>>>>>>>> and >>>>>>>>> the cgroup directory will be no longer accessible from the >>>>>>>>> container. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> So.. how there will be another method (more secure) for giving >>>>>>>> /proc/meminfo >>>>>>>> with limits to the container, right? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Same method. The lxc tools can be configured with a fstab to mount >>>>>>> more >>>>>>> mount points, furthermore if memory.meminfo is available I will add >>>>>>> the >>>>>>> code >>>>>>> to mount it automatically to /proc/meminfo in the lxc tools. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Hmm... setup_fs() from lxc_init.c or another way? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> No, I was thinking in the setup_cgroup() function in conf.c. >>>>> >>>>> Something like: >>>>> >>>>> ... >>>>> >>>>> if (!access("/var/lib/lxc/mycontainer/nsgroup/memory.meminfo"), F_OK) { >>>>> mount("/var/lib/lxc/mycontainer/nsgroup/memory.meminfo", >>>>> "/proc/meminfo", >>>>> MS_BIND, ...); >>>>> } >>>>> >>>>> ... >>>>> >>>>> >>>>> but a bit more clean :) >>>>> >>>>> >>>>> >>>>> >>>>> >>>> hmm... ok, got it, but don't know why does it won't work ;) >>>> >>>> @@ -999,12 +999,14 @@ >>>> static int setup_cgroup(const char *name) >>>> { >>>> char filename[MAXPATHLEN]; >>>> + char meminfofilename[MAXPATHLEN]; >>>> char line[MAXPATHLEN]; >>>> struct stat s; >>>> int ret; >>>> >>>> snprintf(filename, MAXPATHLEN, LXCPATH "/%s/cgroup", name); >>>> - >>>> + snprintf(meminfofilename, MAXPATHLEN, LXCPATH >>>> "/%s/nsgroup/memory.meminfo", name); >>>> + >>>> if (stat(filename, &s)) { >>>> SYSERROR("failed to stat '%s'", filename); >>>> return -1; >>>> @@ -1024,6 +1026,10 @@ >>>> >>>> INFO("cgroup has been setup"); >>>> >>>> + /* mount memory.meminfo as /proc/meminfo */ >>>> + if (!access(meminfofilename, F_OK)) { >>>> + mount(meminfofilename, "/proc/meminfo", "none", MS_BIND, 0); >>>> + } >>>> return 0; >>>> } >>>> >>>> >>>> hmm... any idea Daniel? :) >>>> >>>> >>>> >>>> >>> Yep, can you check the return code of the mount call and return an error >>> ? >>> if (mount(....)) { >>> SYSERROR("failed to mount '%s' to '/proc/meminfo'", meminfofilename); >>> return -1; >>> } >>> at least to verify if this does not fail. >>> and maybe add an INFO trace if the mount is successful saying >>> "/proc/meminfo" is setup with the cgroup. >>> >>> ps : you should launch the command with the "-l INFO" to see the message. >>> >>> >>> >> >> >> >> >> Hmmm.... >> i think that I know where the problem might be: >> >> look here: >> >> lxc1:~# cat debin.log >> lxc-start 1251109397.922 INFO lxc_conf - tty's configured >> lxc-start 1251109397.922 INFO lxc_start - 'debian' is initialized >> lxc-start 1251109397.974 INFO lxc_conf - 'debian' hostname has >> been setup >> lxc-start 1251109397.975 INFO lxc_conf - network has been setup >> lxc-start 1251109397.976 INFO lxc_conf - cgroup has been setup >> lxc-start 1251109397.976 INFO lxc_conf - /proc/meminfo is setup >> with the cgroup >> lxc-start 1251109397.976 INFO lxc_conf - mount points have been >> setup >> lxc-start 1251109397.976 INFO lxc_conf - console '/dev/pts/1' >> mounted to '/usr/local/var/lib/lxc/debian/rootfs/dev/console' >> lxc-start 1251109397.977 INFO lxc_conf - 4 tty(s) has been setup >> lxc-start 1251109397.977 INFO lxc_conf - chrooted to >> '/usr/local/var/lib/lxc/debian/rootfs' >> lxc-start 1251109397.977 INFO lxc_conf - created new pts instance >> lxc-start 1251109397.977 NOTICE lxc_conf - 'debian' is setup. >> lxc-start 1251109397.977 NOTICE lxc_start - exec'ing '/sbin/init' >> lxc-start 1251109397.978 NOTICE lxc_start - '/sbin/init' started >> with pid '24339' >> >> i think that /proc/meminfo should be mounted after /proc . why? i think >> that, because mounting /proc may override /proc/meminfo >> Am I right? :) >> >> > Ha ! haha ! arrgh ! no way ! You are right :/ > Hehe ;) > > In the case of application container, lxc mounts /proc but in the case of > system container it is the system who do that so after the /proc/meminfo has > been mounted. > > Maybe we can look at modifying fs/proc/meminfo.c instead. Let me do a small > patch for the kernel... > > Okey. I am waiting for your patch :) -- Krzysztof Taraszka ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <ac1c4bf20908240431p1fda5a15qd26629618397696-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <ac1c4bf20908240431p1fda5a15qd26629618397696-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2009-08-24 14:11 ` Daniel Lezcano [not found] ` <4A929F83.80207-GANU6spQydw@public.gmane.org> 0 siblings, 1 reply; 43+ messages in thread From: Daniel Lezcano @ 2009-08-24 14:11 UTC (permalink / raw) To: kt-S89nZTSLPHGGdvJs77BJ7Q Cc: Linux Containers, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f [-- Attachment #1: Type: text/plain, Size: 766 bytes --] [ snip ] >>> i think that /proc/meminfo should be mounted after /proc . why? i think >>> that, because mounting /proc may override /proc/meminfo >>> Am I right? :) >>> >>> >>> >> Ha ! haha ! arrgh ! no way ! You are right :/ >> >> > > Hehe ;) > > >> In the case of application container, lxc mounts /proc but in the case of >> system container it is the system who do that so after the /proc/meminfo has >> been mounted. >> >> Maybe we can look at modifying fs/proc/meminfo.c instead. Let me do a small >> patch for the kernel... >> >> >> > Okey. I am waiting for your patch :) Quick and dirty patch but at least working. It is no synced on the latest kernel version. I do not really like to touch fs/proc/meminfo.c but it's an example here. [-- Attachment #2: enhance-meminfo-with-memcontrol.patch --] [-- Type: text/x-diff, Size: 4504 bytes --] Subject: use memory controller to display meminfo From: Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> This patch modify the meminfo code to display informations related to the memory cgroup controller. The ensure the consistency for the tools running in the container. Signed-off-by: Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> --- fs/proc/meminfo.c | 15 ++++++++- include/linux/memcontrol.h | 2 + mm/memcontrol.c | 71 ++++++++++++++++++++++++++++++++------------- 3 files changed, 67 insertions(+), 21 deletions(-) Index: linux-2.6/include/linux/memcontrol.h =================================================================== --- linux-2.6.orig/include/linux/memcontrol.h +++ linux-2.6/include/linux/memcontrol.h @@ -117,6 +117,8 @@ static inline bool mem_cgroup_disabled(v extern bool mem_cgroup_oom_called(struct task_struct *task); +extern int mem_cgroup_info(struct task_struct *task, struct sysinfo *info); + #else /* CONFIG_CGROUP_MEM_RES_CTLR */ struct mem_cgroup; Index: linux-2.6/mm/memcontrol.c =================================================================== --- linux-2.6.orig/mm/memcontrol.c +++ linux-2.6/mm/memcontrol.c @@ -128,6 +128,29 @@ struct mem_cgroup_lru_info { struct mem_cgroup_per_node *nodeinfo[MAX_NUMNODES]; }; +/* For read statistics */ +enum { + MCS_CACHE, + MCS_RSS, + MCS_PGPGIN, + MCS_PGPGOUT, + MCS_INACTIVE_ANON, + MCS_ACTIVE_ANON, + MCS_INACTIVE_FILE, + MCS_ACTIVE_FILE, + MCS_UNEVICTABLE, + NR_MCS_STAT, +}; + +struct mcs_total_stat { + s64 stat[NR_MCS_STAT]; +}; + +static int mem_cgroup_get_local_stat(struct mem_cgroup *mem, void *data); +static void memcg_get_hierarchical_limit(struct mem_cgroup *memcg, + unsigned long long *mem_limit, + unsigned long long *memsw_limit); + /* * The memory controller data structure. The memory controller controls both * page cache and RSS per cgroup. We would eventually like to provide @@ -1794,6 +1817,35 @@ static int mem_cgroup_force_empty_list(s return ret; } +int mem_cgroup_info(struct task_struct *task, struct sysinfo *info) +{ + struct mem_cgroup *mem_cont = mem_cgroup_from_task(task); + struct mcs_total_stat mystat = { }; + u64 limit, memsw_limit, swap_in_u, m_usage, s_usage; + + s_usage = res_counter_read_u64(&mem_cont->memsw, RES_USAGE); + m_usage = res_counter_read_u64(&mem_cont->res, RES_USAGE); + swap_in_u = s_usage - m_usage; + + mem_cgroup_get_local_stat(mem_cont, &mystat); + memcg_get_hierarchical_limit(mem_cont, &limit, &memsw_limit); + + si_meminfo(info); + si_swapinfo(info); + + if (limit != LLONG_MAX) { + info->totalram = limit / info->mem_unit; + info->freeram = (limit - mystat.stat[MCS_RSS]) / info->mem_unit; + } + + if (memsw_limit != LLONG_MAX) { + info->totalswap = memsw_limit / info->mem_unit; + info->freeswap = (memsw_limit - swap_in_u) / info->mem_unit; + } + + return 0; +} + /* * make mem_cgroup's charge to be 0 if there is no task. * This enables deleting this mem_cgroup. @@ -2030,25 +2082,6 @@ static int mem_cgroup_reset(struct cgrou return 0; } - -/* For read statistics */ -enum { - MCS_CACHE, - MCS_RSS, - MCS_PGPGIN, - MCS_PGPGOUT, - MCS_INACTIVE_ANON, - MCS_ACTIVE_ANON, - MCS_INACTIVE_FILE, - MCS_ACTIVE_FILE, - MCS_UNEVICTABLE, - NR_MCS_STAT, -}; - -struct mcs_total_stat { - s64 stat[NR_MCS_STAT]; -}; - struct { char *local_name; char *total_name; Index: linux-2.6/fs/proc/meminfo.c =================================================================== --- linux-2.6.orig/fs/proc/meminfo.c +++ linux-2.6/fs/proc/meminfo.c @@ -10,6 +10,7 @@ #include <linux/seq_file.h> #include <linux/swap.h> #include <linux/vmstat.h> +#include <linux/memcontrol.h> #include <asm/atomic.h> #include <asm/page.h> #include <asm/pgtable.h> @@ -19,6 +20,17 @@ void __attribute__((weak)) arch_report_m { } +static int get_meminfo(struct sysinfo *sysinfo) +{ +#ifdef CONFIG_CGROUP_MEM_RES_CTLR + mem_cgroup_info(current, sysinfo); +#else + si_meminfo(&i); + si_swapinfo(&i); +#endif + return 0; +} + static int meminfo_proc_show(struct seq_file *m, void *v) { struct sysinfo i; @@ -33,8 +45,7 @@ static int meminfo_proc_show(struct seq_ * display in kilobytes. */ #define K(x) ((x) << (PAGE_SHIFT - 10)) - si_meminfo(&i); - si_swapinfo(&i); + get_meminfo(&i); committed = percpu_counter_read_positive(&vm_committed_as); allowed = ((totalram_pages - hugetlb_total_pages()) * sysctl_overcommit_ratio / 100) + total_swap_pages; [-- Attachment #3: Type: text/plain, Size: 206 bytes --] _______________________________________________ Containers mailing list Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org https://lists.linux-foundation.org/mailman/listinfo/containers ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <4A929F83.80207-GANU6spQydw@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <4A929F83.80207-GANU6spQydw@public.gmane.org> @ 2009-08-24 16:26 ` Krzysztof Taraszka [not found] ` <ac1c4bf20908240926j401003dft11f50d3be1466f90-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2009-08-26 1:43 ` KAMEZAWA Hiroyuki 1 sibling, 1 reply; 43+ messages in thread From: Krzysztof Taraszka @ 2009-08-24 16:26 UTC (permalink / raw) To: Daniel Lezcano Cc: Linux Containers, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f 2009/8/24 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> > > > [ snip ] > >> i think that /proc/meminfo should be mounted after /proc . why? i think >>>> that, because mounting /proc may override /proc/meminfo >>>> Am I right? :) >>>> >>>> >>>> >>>> >>> Ha ! haha ! arrgh ! no way ! You are right :/ >>> >>> >>> >> >> Hehe ;) >> >> >> >>> In the case of application container, lxc mounts /proc but in the case of >>> system container it is the system who do that so after the /proc/meminfo >>> has >>> been mounted. >>> >>> Maybe we can look at modifying fs/proc/meminfo.c instead. Let me do a >>> small >>> patch for the kernel... >>> >>> >>> >>> >> Okey. I am waiting for your patch :) >> > > Quick and dirty patch but at least working. It is no synced on the latest > kernel version. > I do not really like to touch fs/proc/meminfo.c but it's an example here. > Hi Daniel, I tried to compile my kernel tree (2.6.30.5) with your patch using gcc-4.4, gcc-4.3 and gcc-4.2 and i got this error on every gcc when linking kernel: mm/built-in.o: In function `mem_cgroup_info': (.text+0x27651): undefined reference to `__udivdi3' mm/built-in.o: In function `mem_cgroup_info': (.text+0x27678): undefined reference to `__udivdi3' mm/built-in.o: In function `mem_cgroup_info': (.text+0x276b0): undefined reference to `__udivdi3' mm/built-in.o: In function `mem_cgroup_info': (.text+0x276dd): undefined reference to `__udivdi3' make: *** [.tmp_vmlinux1] Error 1 this can be gcc based error. What kernel and gcc did you use for compile your kernel? -- Krzysztof Taraszka ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <ac1c4bf20908240926j401003dft11f50d3be1466f90-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <ac1c4bf20908240926j401003dft11f50d3be1466f90-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2009-08-24 16:30 ` Daniel Lezcano [not found] ` <4A92C01E.5010809-GANU6spQydw@public.gmane.org> 0 siblings, 1 reply; 43+ messages in thread From: Daniel Lezcano @ 2009-08-24 16:30 UTC (permalink / raw) To: kt-S89nZTSLPHGGdvJs77BJ7Q Cc: Linux Containers, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Krzysztof Taraszka wrote: > 2009/8/24 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> > >> >> [ snip ] >> >>> i think that /proc/meminfo should be mounted after /proc . why? i think >>>>> that, because mounting /proc may override /proc/meminfo >>>>> Am I right? :) >>>>> >>>>> >>>>> >>>>> >>>> Ha ! haha ! arrgh ! no way ! You are right :/ >>>> >>>> >>>> >>> Hehe ;) >>> >>> >>> >>>> In the case of application container, lxc mounts /proc but in the case of >>>> system container it is the system who do that so after the /proc/meminfo >>>> has >>>> been mounted. >>>> >>>> Maybe we can look at modifying fs/proc/meminfo.c instead. Let me do a >>>> small >>>> patch for the kernel... >>>> >>>> >>>> >>>> >>> Okey. I am waiting for your patch :) >>> >> Quick and dirty patch but at least working. It is no synced on the latest >> kernel version. >> I do not really like to touch fs/proc/meminfo.c but it's an example here. >> > > > Hi Daniel, > > I tried to compile my kernel tree (2.6.30.5) with your patch using gcc-4.4, > gcc-4.3 and gcc-4.2 and i got this error on every gcc when linking kernel: > > mm/built-in.o: In function `mem_cgroup_info': > (.text+0x27651): undefined reference to `__udivdi3' > mm/built-in.o: In function `mem_cgroup_info': > (.text+0x27678): undefined reference to `__udivdi3' > mm/built-in.o: In function `mem_cgroup_info': > (.text+0x276b0): undefined reference to `__udivdi3' > mm/built-in.o: In function `mem_cgroup_info': > (.text+0x276dd): undefined reference to `__udivdi3' > make: *** [.tmp_vmlinux1] Error 1 > > this can be gcc based error. What kernel and gcc did you use for compile > your kernel? I used a 2.6.30 kernel and gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8) Compiled on a x86_64 host. Do you have any warning at the compile time ? ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <4A92C01E.5010809-GANU6spQydw@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <4A92C01E.5010809-GANU6spQydw@public.gmane.org> @ 2009-08-24 16:36 ` Krzysztof Taraszka [not found] ` <ac1c4bf20908240936t1bee38e3h9388298f435f056c-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 43+ messages in thread From: Krzysztof Taraszka @ 2009-08-24 16:36 UTC (permalink / raw) To: Daniel Lezcano Cc: Linux Containers, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f 2009/8/24 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> > Krzysztof Taraszka wrote: > >> 2009/8/24 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >> >> >>> [ snip ] >>> >>> i think that /proc/meminfo should be mounted after /proc . why? i think >>>> >>>>> that, because mounting /proc may override /proc/meminfo >>>>>> Am I right? :) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Ha ! haha ! arrgh ! no way ! You are right :/ >>>>> >>>>> >>>>> >>>>> Hehe ;) >>>> >>>> >>>> >>>> In the case of application container, lxc mounts /proc but in the case >>>>> of >>>>> system container it is the system who do that so after the >>>>> /proc/meminfo >>>>> has >>>>> been mounted. >>>>> >>>>> Maybe we can look at modifying fs/proc/meminfo.c instead. Let me do a >>>>> small >>>>> patch for the kernel... >>>>> >>>>> >>>>> >>>>> >>>>> Okey. I am waiting for your patch :) >>>> >>>> Quick and dirty patch but at least working. It is no synced on the >>> latest >>> kernel version. >>> I do not really like to touch fs/proc/meminfo.c but it's an example here. >>> >>> >> >> Hi Daniel, >> >> I tried to compile my kernel tree (2.6.30.5) with your patch using >> gcc-4.4, >> gcc-4.3 and gcc-4.2 and i got this error on every gcc when linking kernel: >> >> mm/built-in.o: In function `mem_cgroup_info': >> (.text+0x27651): undefined reference to `__udivdi3' >> mm/built-in.o: In function `mem_cgroup_info': >> (.text+0x27678): undefined reference to `__udivdi3' >> mm/built-in.o: In function `mem_cgroup_info': >> (.text+0x276b0): undefined reference to `__udivdi3' >> mm/built-in.o: In function `mem_cgroup_info': >> (.text+0x276dd): undefined reference to `__udivdi3' >> make: *** [.tmp_vmlinux1] Error 1 >> >> this can be gcc based error. What kernel and gcc did you use for compile >> your kernel? >> > > I used a 2.6.30 kernel and > gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8) > Compiled on a x86_64 host. > > Do you have any warning at the compile time ? > > No, did not see any warnings when memcontrol.c or fs/meminfo.c was compiled. Anyway, I will try to build in on the stable (lenny) version of debian (right now I am working on unstable debian tree). That might be gcc from unstable problem. I will let you know what exactly problem is. -- Krzysztof Taraszka ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <ac1c4bf20908240936t1bee38e3h9388298f435f056c-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <ac1c4bf20908240936t1bee38e3h9388298f435f056c-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2009-08-24 19:22 ` Krzysztof Taraszka [not found] ` <ac1c4bf20908241222w127f9f7em5175213281491a8d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 43+ messages in thread From: Krzysztof Taraszka @ 2009-08-24 19:22 UTC (permalink / raw) To: Daniel Lezcano Cc: Linux Containers, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f 2009/8/24 Krzysztof Taraszka <krzysztof.taraszka-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org> > 2009/8/24 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> > >> Krzysztof Taraszka wrote: >> >>> 2009/8/24 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >>> >>> >>>> [ snip ] >>>> >>>> i think that /proc/meminfo should be mounted after /proc . why? i >>>>> think >>>>> >>>>>> that, because mounting /proc may override /proc/meminfo >>>>>>> Am I right? :) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Ha ! haha ! arrgh ! no way ! You are right :/ >>>>>> >>>>>> >>>>>> >>>>>> Hehe ;) >>>>> >>>>> >>>>> >>>>> In the case of application container, lxc mounts /proc but in the case >>>>>> of >>>>>> system container it is the system who do that so after the >>>>>> /proc/meminfo >>>>>> has >>>>>> been mounted. >>>>>> >>>>>> Maybe we can look at modifying fs/proc/meminfo.c instead. Let me do a >>>>>> small >>>>>> patch for the kernel... >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Okey. I am waiting for your patch :) >>>>> >>>>> Quick and dirty patch but at least working. It is no synced on the >>>> latest >>>> kernel version. >>>> I do not really like to touch fs/proc/meminfo.c but it's an example >>>> here. >>>> >>>> >>> >>> Hi Daniel, >>> >>> I tried to compile my kernel tree (2.6.30.5) with your patch using >>> gcc-4.4, >>> gcc-4.3 and gcc-4.2 and i got this error on every gcc when linking >>> kernel: >>> >>> mm/built-in.o: In function `mem_cgroup_info': >>> (.text+0x27651): undefined reference to `__udivdi3' >>> mm/built-in.o: In function `mem_cgroup_info': >>> (.text+0x27678): undefined reference to `__udivdi3' >>> mm/built-in.o: In function `mem_cgroup_info': >>> (.text+0x276b0): undefined reference to `__udivdi3' >>> mm/built-in.o: In function `mem_cgroup_info': >>> (.text+0x276dd): undefined reference to `__udivdi3' >>> make: *** [.tmp_vmlinux1] Error 1 >>> >>> this can be gcc based error. What kernel and gcc did you use for compile >>> your kernel? >>> >> >> I used a 2.6.30 kernel and >> gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8) >> Compiled on a x86_64 host. >> >> Do you have any warning at the compile time ? >> >> > No, did not see any warnings when memcontrol.c or fs/meminfo.c was > compiled. > Anyway, I will try to build in on the stable (lenny) version of debian > (right now I am working on unstable debian tree). > That might be gcc from unstable problem. > > I will let you know what exactly problem is. > > ok Daniel, i found a problem. I am runnning my debian box under vmware 32bit box so your patch can not be compiled propertly on the 32bit system, so I decided to make a little change in your patch. I used shift operation instead of div. in the asm/div64.h is macro do_div() but using shift instead of div is easier that implementing do_div macro, so here is a small patch: --- memcontrol.c.orig 2009-08-24 21:19:36.000000000 +0200 +++ memcontrol.c 2009-08-24 21:20:37.000000000 +0200 @@ -1834,14 +1834,13 @@ si_swapinfo(info); if (limit != LLONG_MAX) { - info->totalram = limit / info->mem_unit; - info->freeram = (limit - mystat.stat[MCS_RSS]) / info->mem_unit; + info->totalram = limit >> info->mem_unit; + info->freeram = (limit - mystat.stat[MCS_RSS]) >> info->mem_unit; } if (memsw_limit != LLONG_MAX) { - info->totalswap = memsw_limit / info->mem_unit; - info->freeswap = (memsw_limit - swap_in_u) / info->mem_unit; - + info->totalswap = memsw_limit >> info->mem_unit; + info->freeswap = (memsw_limit - swap_in_u) >> info->mem_unit; } return 0; I hope that simple change won't to break on your 64bit :) -- Krzysztof Taraszka dzimi-k0Z414SquRyhPH1hqNUYSQ@public.gmane.org ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <ac1c4bf20908241222w127f9f7em5175213281491a8d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <ac1c4bf20908241222w127f9f7em5175213281491a8d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2009-08-24 23:03 ` Krzysztof Taraszka 0 siblings, 0 replies; 43+ messages in thread From: Krzysztof Taraszka @ 2009-08-24 23:03 UTC (permalink / raw) To: Daniel Lezcano Cc: Linux Containers, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f 2009/8/24 Krzysztof Taraszka <krzysztof.taraszka-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org> > > > 2009/8/24 Krzysztof Taraszka <krzysztof.taraszka-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org> > > 2009/8/24 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >> >>> Krzysztof Taraszka wrote: >>> >>>> 2009/8/24 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >>>> >>>> >>>>> [ snip ] >>>>> >>>>> i think that /proc/meminfo should be mounted after /proc . why? i >>>>>> think >>>>>> >>>>>>> that, because mounting /proc may override /proc/meminfo >>>>>>>> Am I right? :) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Ha ! haha ! arrgh ! no way ! You are right :/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hehe ;) >>>>>> >>>>>> >>>>>> >>>>>> In the case of application container, lxc mounts /proc but in the >>>>>>> case of >>>>>>> system container it is the system who do that so after the >>>>>>> /proc/meminfo >>>>>>> has >>>>>>> been mounted. >>>>>>> >>>>>>> Maybe we can look at modifying fs/proc/meminfo.c instead. Let me do a >>>>>>> small >>>>>>> patch for the kernel... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Okey. I am waiting for your patch :) >>>>>> >>>>>> Quick and dirty patch but at least working. It is no synced on the >>>>> latest >>>>> kernel version. >>>>> I do not really like to touch fs/proc/meminfo.c but it's an example >>>>> here. >>>>> >>>>> >>>> >>>> Hi Daniel, >>>> >>>> I tried to compile my kernel tree (2.6.30.5) with your patch using >>>> gcc-4.4, >>>> gcc-4.3 and gcc-4.2 and i got this error on every gcc when linking >>>> kernel: >>>> >>>> mm/built-in.o: In function `mem_cgroup_info': >>>> (.text+0x27651): undefined reference to `__udivdi3' >>>> mm/built-in.o: In function `mem_cgroup_info': >>>> (.text+0x27678): undefined reference to `__udivdi3' >>>> mm/built-in.o: In function `mem_cgroup_info': >>>> (.text+0x276b0): undefined reference to `__udivdi3' >>>> mm/built-in.o: In function `mem_cgroup_info': >>>> (.text+0x276dd): undefined reference to `__udivdi3' >>>> make: *** [.tmp_vmlinux1] Error 1 >>>> >>>> this can be gcc based error. What kernel and gcc did you use for compile >>>> your kernel? >>>> >>> >>> I used a 2.6.30 kernel and >>> gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8) >>> Compiled on a x86_64 host. >>> >>> Do you have any warning at the compile time ? >>> >>> >> No, did not see any warnings when memcontrol.c or fs/meminfo.c was >> compiled. >> Anyway, I will try to build in on the stable (lenny) version of debian >> (right now I am working on unstable debian tree). >> That might be gcc from unstable problem. >> >> I will let you know what exactly problem is. >> >> > ok Daniel, > > i found a problem. I am runnning my debian box under vmware 32bit box so > your patch can not be compiled propertly on the 32bit system, so I decided > to make a little change in your patch. > I used shift operation instead of div. in the asm/div64.h is macro do_div() > but using shift instead of div is easier that implementing do_div macro, so > here is a small patch: > > --- memcontrol.c.orig 2009-08-24 21:19:36.000000000 +0200 > +++ memcontrol.c 2009-08-24 21:20:37.000000000 +0200 > @@ -1834,14 +1834,13 @@ > si_swapinfo(info); > > if (limit != LLONG_MAX) { > - info->totalram = limit / info->mem_unit; > - info->freeram = (limit - mystat.stat[MCS_RSS]) / info->mem_unit; > + info->totalram = limit >> info->mem_unit; > + info->freeram = (limit - mystat.stat[MCS_RSS]) >> info->mem_unit; > } > > if (memsw_limit != LLONG_MAX) { > - info->totalswap = memsw_limit / info->mem_unit; > - info->freeswap = (memsw_limit - swap_in_u) / info->mem_unit; > - > + info->totalswap = memsw_limit >> info->mem_unit; > + info->freeswap = (memsw_limit - swap_in_u) >> info->mem_unit; > } > > return 0; > > > I hope that simple change won't to break on your 64bit :) > > > Agrhhh! It broken at all ;) I forgot that shift operation is true only when the divisor is a power of 2 (if x=2^a then c=c/x is the same as c=c>>x). So.. my last patch only fix compilation on 32bit machines but totaly breaking show values by /proc/meminfo. But.. I make another one which using do_div() macro and working as I wish. It should look like that and it works for me :) --- memcontrol.c.orig 2009-08-24 21:19:36.000000000 +0200 +++ memcontrol.c 2009-08-25 00:56:30.000000000 +0200 @@ -40,6 +40,7 @@ #include "internal.h" #include <asm/uaccess.h> +#include <asm/div64.h> struct cgroup_subsys mem_cgroup_subsys __read_mostly; #define MEM_CGROUP_RECLAIM_RETRIES 5 @@ -1834,14 +1835,27 @@ si_swapinfo(info); if (limit != LLONG_MAX) { - info->totalram = limit / info->mem_unit; - info->freeram = (limit - mystat.stat[MCS_RSS]) / info->mem_unit; + + u64 dd_totalram, dd_freeram; + + dd_totalram = limit; + do_div(dd_totalram, info->mem_unit); + dd_freeram = (limit - mystat.stat[MCS_RSS]); + do_div(dd_freeram, info->mem_unit); + info->totalram = dd_totalram; + info->freeram = dd_freeram; } if (memsw_limit != LLONG_MAX) { - info->totalswap = memsw_limit / info->mem_unit; - info->freeswap = (memsw_limit - swap_in_u) / info->mem_unit; + u64 dd_totalswap, dd_freeswap; + + dd_totalswap = memsw_limit; + do_div(dd_totalswap, info->mem_unit); + dd_freeswap = memsw_limit - swap_in_u; + do_div(dd_freeswap, info->mem_unit); + info->totalswap = dd_totalswap; + info->freeswap = dd_freeswap; } return 0; this should work for 32 & 64bit systems. -- Krzysztof Taraszka dzimi-k0Z414SquRyhPH1hqNUYSQ@public.gmane.org ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [lxc-devel] Memory Resources [not found] ` <4A929F83.80207-GANU6spQydw@public.gmane.org> 2009-08-24 16:26 ` Krzysztof Taraszka @ 2009-08-26 1:43 ` KAMEZAWA Hiroyuki [not found] ` <20090826104312.97ff028f.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 1 sibling, 1 reply; 43+ messages in thread From: KAMEZAWA Hiroyuki @ 2009-08-26 1:43 UTC (permalink / raw) To: Daniel Lezcano Cc: Linux Containers, kt-S89nZTSLPHGGdvJs77BJ7Q, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f On Mon, 24 Aug 2009 16:11:15 +0200 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> wrote: > > > [ snip ] > >>> i think that /proc/meminfo should be mounted after /proc . why? i think > >>> that, because mounting /proc may override /proc/meminfo > >>> Am I right? :) > >>> > >>> > >>> > >> Ha ! haha ! arrgh ! no way ! You are right :/ > >> > >> > > > > Hehe ;) > > > > > >> In the case of application container, lxc mounts /proc but in the case of > >> system container it is the system who do that so after the /proc/meminfo has > >> been mounted. > >> > >> Maybe we can look at modifying fs/proc/meminfo.c instead. Let me do a small > >> patch for the kernel... > >> > >> > >> > > Okey. I am waiting for your patch :) > > Quick and dirty patch but at least working. It is no synced on the > latest kernel version. > I do not really like to touch fs/proc/meminfo.c but it's an example here. > I'll strongly Nack to this. plz find a way to ln -s /path_to_cgroup/memory.meminfo /mycontainer/meminfo or something which doesn't affect users who don't use namespaces. Thanks, -Kame ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <20090826104312.97ff028f.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <20090826104312.97ff028f.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> @ 2009-08-26 12:11 ` Daniel Lezcano [not found] ` <4A952689.9020704-GANU6spQydw@public.gmane.org> 0 siblings, 1 reply; 43+ messages in thread From: Daniel Lezcano @ 2009-08-26 12:11 UTC (permalink / raw) To: KAMEZAWA Hiroyuki Cc: Linux Containers, kt-S89nZTSLPHGGdvJs77BJ7Q, Dietmar Maurer, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f KAMEZAWA Hiroyuki wrote: > On Mon, 24 Aug 2009 16:11:15 +0200 > Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> wrote: > > >> [ snip ] >> >>>>> i think that /proc/meminfo should be mounted after /proc . why? i think >>>>> that, because mounting /proc may override /proc/meminfo >>>>> Am I right? :) >>>>> >>>>> >>>>> >>>>> >>>> Ha ! haha ! arrgh ! no way ! You are right :/ >>>> >>>> >>>> >>> Hehe ;) >>> >>> >>> >>>> In the case of application container, lxc mounts /proc but in the case of >>>> system container it is the system who do that so after the /proc/meminfo has >>>> been mounted. >>>> >>>> Maybe we can look at modifying fs/proc/meminfo.c instead. Let me do a small >>>> patch for the kernel... >>>> >>>> >>>> >>>> >>> Okey. I am waiting for your patch :) >>> >> Quick and dirty patch but at least working. It is no synced on the >> latest kernel version. >> I do not really like to touch fs/proc/meminfo.c but it's an example here. >> >> > > I'll strongly Nack to this. > plz find a way to > ln -s /path_to_cgroup/memory.meminfo /mycontainer/meminfo > Yep, I agree with you, I don't like this approach. We are trying to solve the problem of the userspace tools which look at the /proc/meminfo file to display memory informations. That looks weird to set a max memory usage of 256MB via the cgroup and having the 'free' command showing 4GB of total memory. More than looking weird, Dietmar explained that can puzzle applications relying on these informations for taking some decisions. If we consider having /cgroup/mycontainer/memory.meminfo with memory information in the same format than /proc/meminfo, that solves partially the problem: - we run an application container, the application won't mount /proc so the lxc tools do that for the application (at least to isolate the pids information), it is easy to mount --bind /cgroup/mycontainer/memory.meminfo to /proc/meminfo before the application takes the control, that is to say before 'exec'. Tested and verified with the memory tools (free, top, etc ...) - we run a system container, we can do this mount-bind but when the application, aka /sbin/init, takes the control, the /proc is mounted by the system services, so we lose the /proc/meminfo we previously set. Hence meminfo in the cgroup directory does not solve the problem for this use case. Any ideas ? Thanks -- Daniel ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <4A952689.9020704-GANU6spQydw@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <4A952689.9020704-GANU6spQydw@public.gmane.org> @ 2009-08-26 13:50 ` Krzysztof Taraszka [not found] ` <ac1c4bf20908260650x3311d5d3q44631a30205089b7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 43+ messages in thread From: Krzysztof Taraszka @ 2009-08-26 13:50 UTC (permalink / raw) To: Daniel Lezcano Cc: Linux Containers, Dietmar Maurer, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f 2009/8/26 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> > KAMEZAWA Hiroyuki wrote: > >> On Mon, 24 Aug 2009 16:11:15 +0200 >> Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> wrote: >> >> >> >>> [ snip ] >>> >>> >>>> i think that /proc/meminfo should be mounted after /proc . why? i think >>>>>> that, because mounting /proc may override /proc/meminfo >>>>>> Am I right? :) >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Ha ! haha ! arrgh ! no way ! You are right :/ >>>>> >>>>> >>>>> >>>> Hehe ;) >>>> >>>> >>>> >>>>> In the case of application container, lxc mounts /proc but in the case >>>>> of >>>>> system container it is the system who do that so after the >>>>> /proc/meminfo has >>>>> been mounted. >>>>> >>>>> Maybe we can look at modifying fs/proc/meminfo.c instead. Let me do a >>>>> small >>>>> patch for the kernel... >>>>> >>>>> >>>>> >>>>> >>>> Okey. I am waiting for your patch :) >>>> >>>> >>> Quick and dirty patch but at least working. It is no synced on the latest >>> kernel version. >>> I do not really like to touch fs/proc/meminfo.c but it's an example here. >>> >>> >>> >> >> I'll strongly Nack to this. >> plz find a way to ln -s /path_to_cgroup/memory.meminfo >> /mycontainer/meminfo >> >> > > Yep, I agree with you, I don't like this approach. > > We are trying to solve the problem of the userspace tools which look at the > /proc/meminfo file to display memory informations. That looks weird to set a > max memory usage of 256MB via the cgroup and having the 'free' command > showing 4GB of total memory. More than looking weird, Dietmar explained that > can puzzle applications relying on these informations for taking some > decisions. > > If we consider having /cgroup/mycontainer/memory.meminfo with memory > information in the same format than /proc/meminfo, that solves partially the > problem: > - we run an application container, the application won't mount /proc so the > lxc tools do that for the application (at least to isolate the pids > information), it is easy to mount --bind /cgroup/mycontainer/memory.meminfo > to /proc/meminfo before the application takes the control, that is to say > before 'exec'. Tested and verified with the memory tools (free, top, etc > ...) > > - we run a system container, we can do this mount-bind but when the > application, aka /sbin/init, takes the control, the /proc is mounted by the > system services, so we lose the /proc/meminfo we previously set. Hence > meminfo in the cgroup directory does not solve the problem for this use > case. > > Any ideas ? > > If I may... I have been thinking about that last few days and... I think that mounting /proc/meminfo can be done with mounted cgrop and secured by SMACK64. I will test it tonight and give you raport how does it works for me. ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <ac1c4bf20908260650x3311d5d3q44631a30205089b7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <ac1c4bf20908260650x3311d5d3q44631a30205089b7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2009-08-26 23:25 ` Krzysztof Taraszka [not found] ` <ac1c4bf20908261625g71dff96cu77190056540cbb7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 43+ messages in thread From: Krzysztof Taraszka @ 2009-08-26 23:25 UTC (permalink / raw) To: Daniel Lezcano Cc: Linux Containers, Dietmar Maurer, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f 2009/8/26 Krzysztof Taraszka <krzysztof.taraszka-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org> > 2009/8/26 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> > >> KAMEZAWA Hiroyuki wrote: >> >>> On Mon, 24 Aug 2009 16:11:15 +0200 >>> Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> wrote: >>> >>> >>> >>>> [ snip ] >>>> >>>> >>>>> i think that /proc/meminfo should be mounted after /proc . why? i >>>>>>> think >>>>>>> that, because mounting /proc may override /proc/meminfo >>>>>>> Am I right? :) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Ha ! haha ! arrgh ! no way ! You are right :/ >>>>>> >>>>>> >>>>>> >>>>> Hehe ;) >>>>> >>>>> >>>>> >>>>>> In the case of application container, lxc mounts /proc but in the case >>>>>> of >>>>>> system container it is the system who do that so after the >>>>>> /proc/meminfo has >>>>>> been mounted. >>>>>> >>>>>> Maybe we can look at modifying fs/proc/meminfo.c instead. Let me do a >>>>>> small >>>>>> patch for the kernel... >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Okey. I am waiting for your patch :) >>>>> >>>>> >>>> Quick and dirty patch but at least working. It is no synced on the >>>> latest kernel version. >>>> I do not really like to touch fs/proc/meminfo.c but it's an example >>>> here. >>>> >>>> >>>> >>> >>> I'll strongly Nack to this. >>> plz find a way to ln -s /path_to_cgroup/memory.meminfo >>> /mycontainer/meminfo >>> >>> >> >> Yep, I agree with you, I don't like this approach. >> >> We are trying to solve the problem of the userspace tools which look at >> the /proc/meminfo file to display memory informations. That looks weird to >> set a max memory usage of 256MB via the cgroup and having the 'free' command >> showing 4GB of total memory. More than looking weird, Dietmar explained that >> can puzzle applications relying on these informations for taking some >> decisions. >> >> If we consider having /cgroup/mycontainer/memory.meminfo with memory >> information in the same format than /proc/meminfo, that solves partially the >> problem: >> - we run an application container, the application won't mount /proc so >> the lxc tools do that for the application (at least to isolate the pids >> information), it is easy to mount --bind /cgroup/mycontainer/memory.meminfo >> to /proc/meminfo before the application takes the control, that is to say >> before 'exec'. Tested and verified with the memory tools (free, top, etc >> ...) >> >> - we run a system container, we can do this mount-bind but when the >> application, aka /sbin/init, takes the control, the /proc is mounted by the >> system services, so we lose the /proc/meminfo we previously set. Hence >> meminfo in the cgroup directory does not solve the problem for this use >> case. >> >> Any ideas ? >> >> > If I may... I have been thinking about that last few days and... I think > that mounting /proc/meminfo can be done with mounted cgrop and secured by > SMACK64. > I will test it tonight and give you raport how does it works for me. > > Okey. I made few tests and this two ways work: First way: ======= lxc. smack enabled, policy loaded. cgroup not labeled. a) start container b) mount cgroup inside container c) mount --bind /cgroup/foo/memory.meminfo /proc/meminfo d) secure the /cgroup on the host (ie: attr -S -s SMACK64 -V host /cgroup). this step can be done inside lxc tools ;) Second way: ========== lxc. smack enabled, policy loaded. cgroup not labeled. a) do not label whole /cgrop directory (DO NOT DO: attr -S -s SMACK64 -V host /cgroup). Label dedicate files only (for example: /cgroup/cpuset.cpus, /cgroup/vs1/cpuset.cpus, etc). Do not label the /cgrop/vs1 directory. Label with vs1 label only /cgroup/vs1/memory.meminfo. All other files label with host label to do not allow read them. b) start container c) mount cgroup inside container d) mount --bind /cgroup/foo/memory.meminfo /proc/meminfo steps: b, c, d can be done inside lxc tools. step a can't and it is base on the admin policy. I think that the first solution is more automatic and can be done by lxc tools (maybe command line switch? I can prepare a patch for that. -- Krzysztof Taraszka ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <ac1c4bf20908261625g71dff96cu77190056540cbb7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <ac1c4bf20908261625g71dff96cu77190056540cbb7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2009-08-28 9:32 ` Daniel Lezcano [not found] ` <4A97A448.5050506-GANU6spQydw@public.gmane.org> 0 siblings, 1 reply; 43+ messages in thread From: Daniel Lezcano @ 2009-08-28 9:32 UTC (permalink / raw) To: kt-S89nZTSLPHGGdvJs77BJ7Q Cc: Linux Containers, Dietmar Maurer, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Krzysztof Taraszka wrote: > 2009/8/26 Krzysztof Taraszka <krzysztof.taraszka-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org> > > >> 2009/8/26 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> >> >> >>> KAMEZAWA Hiroyuki wrote: >>> >>> >>>> On Mon, 24 Aug 2009 16:11:15 +0200 >>>> Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> wrote: >>>> >>>> >>>> >>>> >>>>> [ snip ] >>>>> >>>>> >>>>> >>>>>> i think that /proc/meminfo should be mounted after /proc . why? i >>>>>> >>>>>>>> think >>>>>>>> that, because mounting /proc may override /proc/meminfo >>>>>>>> Am I right? :) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Ha ! haha ! arrgh ! no way ! You are right :/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Hehe ;) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> In the case of application container, lxc mounts /proc but in the case >>>>>>> of >>>>>>> system container it is the system who do that so after the >>>>>>> /proc/meminfo has >>>>>>> been mounted. >>>>>>> >>>>>>> Maybe we can look at modifying fs/proc/meminfo.c instead. Let me do a >>>>>>> small >>>>>>> patch for the kernel... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Okey. I am waiting for your patch :) >>>>>> >>>>>> >>>>>> >>>>> Quick and dirty patch but at least working. It is no synced on the >>>>> latest kernel version. >>>>> I do not really like to touch fs/proc/meminfo.c but it's an example >>>>> here. >>>>> >>>>> >>>>> >>>>> >>>> I'll strongly Nack to this. >>>> plz find a way to ln -s /path_to_cgroup/memory.meminfo >>>> /mycontainer/meminfo >>>> >>>> >>>> >>> Yep, I agree with you, I don't like this approach. >>> >>> We are trying to solve the problem of the userspace tools which look at >>> the /proc/meminfo file to display memory informations. That looks weird to >>> set a max memory usage of 256MB via the cgroup and having the 'free' command >>> showing 4GB of total memory. More than looking weird, Dietmar explained that >>> can puzzle applications relying on these informations for taking some >>> decisions. >>> >>> If we consider having /cgroup/mycontainer/memory.meminfo with memory >>> information in the same format than /proc/meminfo, that solves partially the >>> problem: >>> - we run an application container, the application won't mount /proc so >>> the lxc tools do that for the application (at least to isolate the pids >>> information), it is easy to mount --bind /cgroup/mycontainer/memory.meminfo >>> to /proc/meminfo before the application takes the control, that is to say >>> before 'exec'. Tested and verified with the memory tools (free, top, etc >>> ...) >>> >>> - we run a system container, we can do this mount-bind but when the >>> application, aka /sbin/init, takes the control, the /proc is mounted by the >>> system services, so we lose the /proc/meminfo we previously set. Hence >>> meminfo in the cgroup directory does not solve the problem for this use >>> case. >>> >>> Any ideas ? >>> >>> >>> >> If I may... I have been thinking about that last few days and... I think >> that mounting /proc/meminfo can be done with mounted cgrop and secured by >> SMACK64. >> I will test it tonight and give you raport how does it works for me. >> >> >> > > Okey. > I made few tests and this two ways work: > > First way: > ======= > lxc. smack enabled, policy loaded. cgroup not labeled. > > a) start container > b) mount cgroup inside container > c) mount --bind /cgroup/foo/memory.meminfo /proc/meminfo > d) secure the /cgroup on the host (ie: attr -S -s SMACK64 -V host /cgroup). > > this step can be done inside lxc tools ;) > > Second way: > ========== > lxc. smack enabled, policy loaded. cgroup not labeled. > > a) do not label whole /cgrop directory (DO NOT DO: attr -S -s SMACK64 -V > host /cgroup). Label dedicate files only (for example: /cgroup/cpuset.cpus, > /cgroup/vs1/cpuset.cpus, etc). Do not label the /cgrop/vs1 directory. Label > with vs1 label only /cgroup/vs1/memory.meminfo. All other files label with > host label to do not allow read them. > b) start container > c) mount cgroup inside container > d) mount --bind /cgroup/foo/memory.meminfo /proc/meminfo > > steps: b, c, d can be done inside lxc tools. step a can't and it is base on > the admin policy. > > I think that the first solution is more automatic and can be done by lxc > tools (maybe command line switch? I can prepare a patch for that. > I do not know smack, what does smack here ? Will this solution avoid the container to overwrite /proc/meminfo by remounting /proc ? ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <4A97A448.5050506-GANU6spQydw@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <4A97A448.5050506-GANU6spQydw@public.gmane.org> @ 2009-08-30 23:56 ` KAMEZAWA Hiroyuki [not found] ` <20090831085606.b7207a76.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2009-08-31 13:40 ` Serge E. Hallyn 1 sibling, 1 reply; 43+ messages in thread From: KAMEZAWA Hiroyuki @ 2009-08-30 23:56 UTC (permalink / raw) To: Daniel Lezcano Cc: Linux Containers, kt-S89nZTSLPHGGdvJs77BJ7Q, Dietmar Maurer, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f On Fri, 28 Aug 2009 11:32:56 +0200 Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> wrote: > > steps: b, c, d can be done inside lxc tools. step a can't and it is base on > > the admin policy. > > > > I think that the first solution is more automatic and can be done by lxc > > tools (maybe command line switch? I can prepare a patch for that. > > > > I do not know smack, what does smack here ? Will this solution avoid the > container to overwrite /proc/meminfo by remounting /proc ? > Hmm, how about supporting custom FUSE for private-proc by user land ? It seems what virtualized hosts want to see is different from what kernel shows. For example, you can show correct "uptime" for virtualized environ. Thanks, -Kame ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <20090831085606.b7207a76.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <20090831085606.b7207a76.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> @ 2009-08-31 9:24 ` Daniel Lezcano [not found] ` <4A9B96B7.9060009-GANU6spQydw@public.gmane.org> 0 siblings, 1 reply; 43+ messages in thread From: Daniel Lezcano @ 2009-08-31 9:24 UTC (permalink / raw) To: KAMEZAWA Hiroyuki Cc: Linux Containers, kt-S89nZTSLPHGGdvJs77BJ7Q, Dietmar Maurer, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f KAMEZAWA Hiroyuki wrote: > On Fri, 28 Aug 2009 11:32:56 +0200 > Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org> wrote: > >>> steps: b, c, d can be done inside lxc tools. step a can't and it is base on >>> the admin policy. >>> >>> I think that the first solution is more automatic and can be done by lxc >>> tools (maybe command line switch? I can prepare a patch for that. >>> >>> >> I do not know smack, what does smack here ? Will this solution avoid the >> container to overwrite /proc/meminfo by remounting /proc ? >> >> > Hmm, how about supporting custom FUSE for private-proc by user land ? > It seems what virtualized hosts want to see is different from what kernel shows. > For example, you can show correct "uptime" for virtualized environ. > Yep, interesting and maybe a solution for the application containers. In the case of the system container, that will be the distro scripts which will mount the /proc directory with the usual mount options. The objective is to avoid to modify the distro scripts and let them do the work, like mounting /proc. If we use a fuse procfs, we will need to change these scripts to do the correct mount, no ? (note we have the same problem with /cgroup/meminfo solution). -- Daniel ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <4A9B96B7.9060009-GANU6spQydw@public.gmane.org>]
* RE: [lxc-devel] Memory Resources [not found] ` <4A9B96B7.9060009-GANU6spQydw@public.gmane.org> @ 2009-08-31 10:02 ` Dietmar Maurer 0 siblings, 0 replies; 43+ messages in thread From: Dietmar Maurer @ 2009-08-31 10:02 UTC (permalink / raw) To: Daniel Lezcano, KAMEZAWA Hiroyuki Cc: Linux Containers, kt-S89nZTSLPHGGdvJs77BJ7Q@public.gmane.org, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > Yep, interesting and maybe a solution for the application containers. > In the case of the system container, that will be the distro scripts > which will mount the /proc directory with the usual mount options. The > objective is to avoid to modify the distro scripts and let them do the > work, like mounting /proc. If we use a fuse procfs, we will need to > change these scripts to do the correct mount, no ? (note we have the > same problem with /cgroup/meminfo solution). Don't know, but maybe it is possible to 'map' the 'proc' filesystem type to an existing directory (bind mount)? - Dietmar ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [lxc-devel] Memory Resources [not found] ` <4A97A448.5050506-GANU6spQydw@public.gmane.org> 2009-08-30 23:56 ` KAMEZAWA Hiroyuki @ 2009-08-31 13:40 ` Serge E. Hallyn [not found] ` <20090831134045.GD4837-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> 1 sibling, 1 reply; 43+ messages in thread From: Serge E. Hallyn @ 2009-08-31 13:40 UTC (permalink / raw) To: Daniel Lezcano Cc: Linux Containers, kt-S89nZTSLPHGGdvJs77BJ7Q, Dietmar Maurer, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Quoting Daniel Lezcano (daniel.lezcano-GANU6spQydw@public.gmane.org): > Krzysztof Taraszka wrote: > > Okey. > > I made few tests and this two ways work: > > > > First way: > > ======= > > lxc. smack enabled, policy loaded. cgroup not labeled. > > > > a) start container > > b) mount cgroup inside container > > c) mount --bind /cgroup/foo/memory.meminfo /proc/meminfo > > d) secure the /cgroup on the host (ie: attr -S -s SMACK64 -V host /cgroup). > > > > this step can be done inside lxc tools ;) > > > > Second way: > > ========== > > lxc. smack enabled, policy loaded. cgroup not labeled. > > > > a) do not label whole /cgrop directory (DO NOT DO: attr -S -s SMACK64 -V > > host /cgroup). Label dedicate files only (for example: /cgroup/cpuset.cpus, > > /cgroup/vs1/cpuset.cpus, etc). Do not label the /cgrop/vs1 directory. Label > > with vs1 label only /cgroup/vs1/memory.meminfo. All other files label with > > host label to do not allow read them. > > b) start container > > c) mount cgroup inside container > > d) mount --bind /cgroup/foo/memory.meminfo /proc/meminfo > > > > steps: b, c, d can be done inside lxc tools. step a can't and it is base on > > the admin policy. > > > > I think that the first solution is more automatic and can be done by lxc > > tools (maybe command line switch? I can prepare a patch for that. > > > > I do not know smack, what does smack here ? Will this solution avoid the > container to overwrite /proc/meminfo by remounting /proc ? Right, in the first way he is labeling the whole cgroupfs with a label which prevents the container from mounting it. In the second way, the specific files are labeled. -serge ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <20090831134045.GD4837-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <20090831134045.GD4837-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> @ 2009-08-31 14:41 ` Daniel Lezcano [not found] ` <4A9BE134.5040804-GANU6spQydw@public.gmane.org> 0 siblings, 1 reply; 43+ messages in thread From: Daniel Lezcano @ 2009-08-31 14:41 UTC (permalink / raw) To: Serge E. Hallyn Cc: Linux Containers, kt-S89nZTSLPHGGdvJs77BJ7Q, Dietmar Maurer, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Serge E. Hallyn wrote: > Quoting Daniel Lezcano (daniel.lezcano-GANU6spQydw@public.gmane.org): > >> Krzysztof Taraszka wrote: >> >>> Okey. >>> I made few tests and this two ways work: >>> >>> First way: >>> ======= >>> lxc. smack enabled, policy loaded. cgroup not labeled. >>> >>> a) start container >>> b) mount cgroup inside container >>> c) mount --bind /cgroup/foo/memory.meminfo /proc/meminfo >>> d) secure the /cgroup on the host (ie: attr -S -s SMACK64 -V host /cgroup). >>> >>> this step can be done inside lxc tools ;) >>> >>> Second way: >>> ========== >>> lxc. smack enabled, policy loaded. cgroup not labeled. >>> >>> a) do not label whole /cgrop directory (DO NOT DO: attr -S -s SMACK64 -V >>> host /cgroup). Label dedicate files only (for example: /cgroup/cpuset.cpus, >>> /cgroup/vs1/cpuset.cpus, etc). Do not label the /cgrop/vs1 directory. Label >>> with vs1 label only /cgroup/vs1/memory.meminfo. All other files label with >>> host label to do not allow read them. >>> b) start container >>> c) mount cgroup inside container >>> d) mount --bind /cgroup/foo/memory.meminfo /proc/meminfo >>> >>> steps: b, c, d can be done inside lxc tools. step a can't and it is base on >>> the admin policy. >>> >>> I think that the first solution is more automatic and can be done by lxc >>> tools (maybe command line switch? I can prepare a patch for that. >>> >>> >> I do not know smack, what does smack here ? Will this solution avoid the >> container to overwrite /proc/meminfo by remounting /proc ? >> > > Right, in the first way he is labeling the whole cgroupfs with a label > which prevents the container from mounting it. In the second way, > the specific files are labeled. > Ah, got it ! :) The idea of Kamezawa-san to use a fuse proc is maybe a good idea in this case. So we can address the entire /proc specific informations. For example, like the /proc/meminfo, there is the /proc/cpuinfo. If you restrict the usage to a subset of your cpus with cpuset and you look at /proc/cpuinfo, you see all the cpus; it is not a big problem until a computation application looks at this file and choose to fork(n cpus) and set the affinity of each process to each cpu ... AFAIR, this is the case for HPC applications. ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <4A9BE134.5040804-GANU6spQydw@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <4A9BE134.5040804-GANU6spQydw@public.gmane.org> @ 2009-08-31 14:54 ` Serge E. Hallyn [not found] ` <20090831145423.GA8107-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> 0 siblings, 1 reply; 43+ messages in thread From: Serge E. Hallyn @ 2009-08-31 14:54 UTC (permalink / raw) To: Daniel Lezcano Cc: Linux Containers, kt-S89nZTSLPHGGdvJs77BJ7Q, Dietmar Maurer, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Quoting Daniel Lezcano (daniel.lezcano-GANU6spQydw@public.gmane.org): > Serge E. Hallyn wrote: >> Quoting Daniel Lezcano (daniel.lezcano-GANU6spQydw@public.gmane.org): >> >>> Krzysztof Taraszka wrote: >>> >>>> Okey. >>>> I made few tests and this two ways work: >>>> >>>> First way: >>>> ======= >>>> lxc. smack enabled, policy loaded. cgroup not labeled. >>>> >>>> a) start container >>>> b) mount cgroup inside container >>>> c) mount --bind /cgroup/foo/memory.meminfo /proc/meminfo >>>> d) secure the /cgroup on the host (ie: attr -S -s SMACK64 -V host /cgroup). >>>> >>>> this step can be done inside lxc tools ;) >>>> >>>> Second way: >>>> ========== >>>> lxc. smack enabled, policy loaded. cgroup not labeled. >>>> >>>> a) do not label whole /cgrop directory (DO NOT DO: attr -S -s SMACK64 -V >>>> host /cgroup). Label dedicate files only (for example: /cgroup/cpuset.cpus, >>>> /cgroup/vs1/cpuset.cpus, etc). Do not label the /cgrop/vs1 directory. Label >>>> with vs1 label only /cgroup/vs1/memory.meminfo. All other files label with >>>> host label to do not allow read them. >>>> b) start container >>>> c) mount cgroup inside container >>>> d) mount --bind /cgroup/foo/memory.meminfo /proc/meminfo >>>> >>>> steps: b, c, d can be done inside lxc tools. step a can't and it is base on >>>> the admin policy. >>>> >>>> I think that the first solution is more automatic and can be done by lxc >>>> tools (maybe command line switch? I can prepare a patch for that. >>>> >>> I do not know smack, what does smack here ? Will this solution avoid >>> the container to overwrite /proc/meminfo by remounting /proc ? >>> >> >> Right, in the first way he is labeling the whole cgroupfs with a label >> which prevents the container from mounting it. In the second way, >> the specific files are labeled. >> > > Ah, got it ! :) > > The idea of Kamezawa-san to use a fuse proc is maybe a good idea in this > case. So we can address the entire /proc specific informations. For I agree, nice idea. And hopefully pretty simple to whip up for the meminfo and cpuinfo files as an example. Are you thinking a fuse fs which takes a config file, holds an open ref to its ancestor /proc, and for each file looks in a config file to decide whether to show userspace: 1. nothing 2. the underlying file, unprocessed 3. a simple ascii file instead 4. the underlying file, processed? > example, like the /proc/meminfo, there is the /proc/cpuinfo. If you > restrict the usage to a subset of your cpus with cpuset and you look at > /proc/cpuinfo, you see all the cpus; it is not a big problem until a > computation application looks at this file and choose to fork(n cpus) > and set the affinity of each process to each cpu ... AFAIR, this is the > case for HPC applications. -serge ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <20090831145423.GA8107-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <20090831145423.GA8107-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> @ 2009-08-31 15:18 ` Daniel Lezcano [not found] ` <4A9BE9A9.1080907-GANU6spQydw@public.gmane.org> 0 siblings, 1 reply; 43+ messages in thread From: Daniel Lezcano @ 2009-08-31 15:18 UTC (permalink / raw) To: Serge E. Hallyn Cc: Linux Containers, kt-S89nZTSLPHGGdvJs77BJ7Q, Dietmar Maurer, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Serge E. Hallyn wrote: > Quoting Daniel Lezcano (daniel.lezcano-GANU6spQydw@public.gmane.org): > >> Serge E. Hallyn wrote: >> >>> Quoting Daniel Lezcano (daniel.lezcano-GANU6spQydw@public.gmane.org): >>> >>> >>>> Krzysztof Taraszka wrote: >>>> >>>> >>>>> Okey. >>>>> I made few tests and this two ways work: >>>>> >>>>> First way: >>>>> ======= >>>>> lxc. smack enabled, policy loaded. cgroup not labeled. >>>>> >>>>> a) start container >>>>> b) mount cgroup inside container >>>>> c) mount --bind /cgroup/foo/memory.meminfo /proc/meminfo >>>>> d) secure the /cgroup on the host (ie: attr -S -s SMACK64 -V host /cgroup). >>>>> >>>>> this step can be done inside lxc tools ;) >>>>> >>>>> Second way: >>>>> ========== >>>>> lxc. smack enabled, policy loaded. cgroup not labeled. >>>>> >>>>> a) do not label whole /cgrop directory (DO NOT DO: attr -S -s SMACK64 -V >>>>> host /cgroup). Label dedicate files only (for example: /cgroup/cpuset.cpus, >>>>> /cgroup/vs1/cpuset.cpus, etc). Do not label the /cgrop/vs1 directory. Label >>>>> with vs1 label only /cgroup/vs1/memory.meminfo. All other files label with >>>>> host label to do not allow read them. >>>>> b) start container >>>>> c) mount cgroup inside container >>>>> d) mount --bind /cgroup/foo/memory.meminfo /proc/meminfo >>>>> >>>>> steps: b, c, d can be done inside lxc tools. step a can't and it is base on >>>>> the admin policy. >>>>> >>>>> I think that the first solution is more automatic and can be done by lxc >>>>> tools (maybe command line switch? I can prepare a patch for that. >>>>> >>>>> >>>> I do not know smack, what does smack here ? Will this solution avoid >>>> the container to overwrite /proc/meminfo by remounting /proc ? >>>> >>>> >>> Right, in the first way he is labeling the whole cgroupfs with a label >>> which prevents the container from mounting it. In the second way, >>> the specific files are labeled. >>> >>> >> Ah, got it ! :) >> >> The idea of Kamezawa-san to use a fuse proc is maybe a good idea in this >> case. So we can address the entire /proc specific informations. For >> > > I agree, nice idea. And hopefully pretty simple to whip up for the > meminfo and cpuinfo files as an example. > > Are you thinking a fuse fs which takes a config file, holds an open > ref to its ancestor /proc, and for each file looks in a config file to > decide whether to show userspace: > 1. nothing > 2. the underlying file, unprocessed > 3. a simple ascii file instead > 4. the underlying file, processed? > Yes, exactly :) But, I am not sure how to retrieve the container context, I mean how to pick and return the right information. eg: in the container foo, when looking at /proc/meminfo, fuse-lxcfs should process /cgroup/foo/(somefiles), how to know the request is coming from 'foo' without doing multiple mount, one in each container ? >> example, like the /proc/meminfo, there is the /proc/cpuinfo. If you >> restrict the usage to a subset of your cpus with cpuset and you look at >> /proc/cpuinfo, you see all the cpus; it is not a big problem until a >> computation application looks at this file and choose to fork(n cpus) >> and set the affinity of each process to each cpu ... AFAIR, this is the >> case for HPC applications. >> ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <4A9BE9A9.1080907-GANU6spQydw@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <4A9BE9A9.1080907-GANU6spQydw@public.gmane.org> @ 2009-08-31 15:47 ` Daniel Lezcano 2009-08-31 16:31 ` Serge E. Hallyn 1 sibling, 0 replies; 43+ messages in thread From: Daniel Lezcano @ 2009-08-31 15:47 UTC (permalink / raw) To: kt-S89nZTSLPHGGdvJs77BJ7Q Cc: Linux Containers, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Daniel Lezcano wrote: > Serge E. Hallyn wrote: > >> Quoting Daniel Lezcano (daniel.lezcano-GANU6spQydw@public.gmane.org): >> >> >>> Serge E. Hallyn wrote: >>> >>> >>>> Quoting Daniel Lezcano (daniel.lezcano-GANU6spQydw@public.gmane.org): >>>> >>>> >>>> >>>>> Krzysztof Taraszka wrote: >>>>> >>>>> >>>>> >>>>>> Okey. >>>>>> I made few tests and this two ways work: >>>>>> >>>>>> First way: >>>>>> ======= >>>>>> lxc. smack enabled, policy loaded. cgroup not labeled. >>>>>> >>>>>> a) start container >>>>>> b) mount cgroup inside container >>>>>> c) mount --bind /cgroup/foo/memory.meminfo /proc/meminfo >>>>>> d) secure the /cgroup on the host (ie: attr -S -s SMACK64 -V host /cgroup). >>>>>> >>>>>> this step can be done inside lxc tools ;) >>>>>> >>>>>> Second way: >>>>>> ========== >>>>>> lxc. smack enabled, policy loaded. cgroup not labeled. >>>>>> >>>>>> a) do not label whole /cgrop directory (DO NOT DO: attr -S -s SMACK64 -V >>>>>> host /cgroup). Label dedicate files only (for example: /cgroup/cpuset.cpus, >>>>>> /cgroup/vs1/cpuset.cpus, etc). Do not label the /cgrop/vs1 directory. Label >>>>>> with vs1 label only /cgroup/vs1/memory.meminfo. All other files label with >>>>>> host label to do not allow read them. >>>>>> b) start container >>>>>> c) mount cgroup inside container >>>>>> d) mount --bind /cgroup/foo/memory.meminfo /proc/meminfo >>>>>> >>>>>> steps: b, c, d can be done inside lxc tools. step a can't and it is base on >>>>>> the admin policy. >>>>>> >>>>>> I think that the first solution is more automatic and can be done by lxc >>>>>> tools (maybe command line switch? I can prepare a patch for that. >>>>>> >>>>>> >>>>>> >>>>> I do not know smack, what does smack here ? Will this solution avoid >>>>> the container to overwrite /proc/meminfo by remounting /proc ? >>>>> >>>>> >>>>> >>>> Right, in the first way he is labeling the whole cgroupfs with a label >>>> which prevents the container from mounting it. In the second way, >>>> the specific files are labeled. >>>> >>>> >>>> >>> Ah, got it ! :) >>> >>> The idea of Kamezawa-san to use a fuse proc is maybe a good idea in this >>> case. So we can address the entire /proc specific informations. For >>> >>> >> I agree, nice idea. And hopefully pretty simple to whip up for the >> meminfo and cpuinfo files as an example. >> >> Are you thinking a fuse fs which takes a config file, holds an open >> ref to its ancestor /proc, and for each file looks in a config file to >> decide whether to show userspace: >> 1. nothing >> 2. the underlying file, unprocessed >> 3. a simple ascii file instead >> 4. the underlying file, processed? >> >> > > Yes, exactly :) > But, I am not sure how to retrieve the container context, I mean how to > pick and return the right information. > eg: in the container foo, when looking at /proc/meminfo, fuse-lxcfs > should process /cgroup/foo/(somefiles), how to know the request is > coming from 'foo' without doing multiple mount, one in each container ? > > >>> example, like the /proc/meminfo, there is the /proc/cpuinfo. If you >>> restrict the usage to a subset of your cpus with cpuset and you look at >>> /proc/cpuinfo, you see all the cpus; it is not a big problem until a >>> computation application looks at this file and choose to fork(n cpus) >>> and set the affinity of each process to each cpu ... AFAIR, this is the >>> case for HPC applications. >>> >>> Krzysztof, what do think about this solution ? ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [lxc-devel] Memory Resources [not found] ` <4A9BE9A9.1080907-GANU6spQydw@public.gmane.org> 2009-08-31 15:47 ` Daniel Lezcano @ 2009-08-31 16:31 ` Serge E. Hallyn [not found] ` <20090831163114.GA13896-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> 1 sibling, 1 reply; 43+ messages in thread From: Serge E. Hallyn @ 2009-08-31 16:31 UTC (permalink / raw) To: Daniel Lezcano Cc: Linux Containers, kt-S89nZTSLPHGGdvJs77BJ7Q, Dietmar Maurer, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Quoting Daniel Lezcano (daniel.lezcano-GANU6spQydw@public.gmane.org): > Serge E. Hallyn wrote: >>> The idea of Kamezawa-san to use a fuse proc is maybe a good idea in >>> this case. So we can address the entire /proc specific informations. >>> For >> >> I agree, nice idea. And hopefully pretty simple to whip up for the >> meminfo and cpuinfo files as an example. >> >> Are you thinking a fuse fs which takes a config file, holds an open >> ref to its ancestor /proc, and for each file looks in a config file to >> decide whether to show userspace: >> 1. nothing >> 2. the underlying file, unprocessed >> 3. a simple ascii file instead >> 4. the underlying file, processed? >> > > Yes, exactly :) > But, I am not sure how to retrieve the container context, I mean how to > pick and return the right information. > eg: in the container foo, when looking at /proc/meminfo, fuse-lxcfs > should process /cgroup/foo/(somefiles), how to know the request is > coming from 'foo' without doing multiple mount, one in each container ? Why without doing one mount per container? :) I figure the container can be responsible for the actual mounting, if it cares. The host/kernel should keep it *safe* for the container to use unfiltered /proc (, /sys, /cgroup, etc), but the container can be responsible for filtering it however much it feels necessary. (That fits with the 2006 kernel summit pseudo-decree that we are not trying to fake a container into thinking it is a real host, only make the container useful.) Are you worried about the extra memory overhead? -serge ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <20090831163114.GA13896-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]
* Re: [lxc-devel] Memory Resources [not found] ` <20090831163114.GA13896-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> @ 2009-09-01 18:37 ` Daniel Lezcano 0 siblings, 0 replies; 43+ messages in thread From: Daniel Lezcano @ 2009-09-01 18:37 UTC (permalink / raw) To: Serge E. Hallyn Cc: Linux Containers, kt-S89nZTSLPHGGdvJs77BJ7Q, Dietmar Maurer, lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f Serge E. Hallyn wrote: > Quoting Daniel Lezcano (daniel.lezcano-GANU6spQydw@public.gmane.org): > >> Serge E. Hallyn wrote: >> >>>> The idea of Kamezawa-san to use a fuse proc is maybe a good idea in >>>> this case. So we can address the entire /proc specific informations. >>>> For >>>> >>> I agree, nice idea. And hopefully pretty simple to whip up for the >>> meminfo and cpuinfo files as an example. >>> >>> Are you thinking a fuse fs which takes a config file, holds an open >>> ref to its ancestor /proc, and for each file looks in a config file to >>> decide whether to show userspace: >>> 1. nothing >>> 2. the underlying file, unprocessed >>> 3. a simple ascii file instead >>> 4. the underlying file, processed? >>> >>> >> Yes, exactly :) >> But, I am not sure how to retrieve the container context, I mean how to >> pick and return the right information. >> eg: in the container foo, when looking at /proc/meminfo, fuse-lxcfs >> should process /cgroup/foo/(somefiles), how to know the request is >> coming from 'foo' without doing multiple mount, one in each container ? >> > > Why without doing one mount per container? :) > > I figure the container can be responsible for the actual mounting, > if it cares. The host/kernel should keep it *safe* for the container > to use unfiltered /proc (, /sys, /cgroup, etc), but the container > can be responsible for filtering it however much it feels necessary. > > (That fits with the 2006 kernel summit pseudo-decree that we are not > trying to fake a container into thinking it is a real host, only > make the container useful.) > > Are you worried about the extra memory overhead? > Well, I am used to see a single instance of a daemon like sshfs :) I am not used of fuse, I will play a bit with a trivial fuse-lxcfs to see how that behaves with a container. ^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2009-09-01 18:37 UTC | newest]
Thread overview: 43+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <ac1c4bf20908230513q383fb338ne02e8f19f6ef18a6@mail.gmail.com>
[not found] ` <ac1c4bf20908230513q383fb338ne02e8f19f6ef18a6-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-08-23 16:18 ` [lxc-devel] Memory Resources Daniel Lezcano
[not found] ` <4A916BC9.8040905-GANU6spQydw@public.gmane.org>
2009-08-23 16:59 ` Krzysztof Taraszka
[not found] ` <ac1c4bf20908230959j4cda58cel3bcf4f3822d50bb1-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-08-23 18:00 ` Daniel Lezcano
[not found] ` <4A9183B2.7090005-GANU6spQydw@public.gmane.org>
2009-08-23 18:17 ` Krzysztof Taraszka
[not found] ` <ac1c4bf20908231117sb180e78q3eed64db3573ec35-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-08-23 18:38 ` Krzysztof Taraszka
[not found] ` <ac1c4bf20908231138j2ce7bb48v69a8ac8ede6bc314-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-08-23 19:22 ` Krzysztof Taraszka
[not found] ` <ac1c4bf20908231222t182e6ca6u716b98e13d85cbad-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-08-23 20:05 ` Daniel Lezcano
[not found] ` <4A91A103.6020207-GANU6spQydw@public.gmane.org>
2009-08-23 20:18 ` Krzysztof Taraszka
[not found] ` <ac1c4bf20908231318v1586c2ciffd3df5fe1b70c20-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-08-23 21:00 ` Daniel Lezcano
[not found] ` <4A91ADE1.9090204-GANU6spQydw@public.gmane.org>
2009-08-23 21:12 ` Krzysztof Taraszka
[not found] ` <ac1c4bf20908231412m634fdf9h686f6bd24eb95a14-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-08-24 0:27 ` KAMEZAWA Hiroyuki
[not found] ` <20090824092739.70d56a5b.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2009-08-24 0:40 ` Krzysztof Taraszka
2009-08-24 6:17 ` [Devel] " Dietmar Maurer
[not found] ` <90D306BE6EBC8D428A824FBBA7A3113DE076E221-jRgWbcutxcWenyD9vqZGNUEOCMrvLtNR@public.gmane.org>
2009-08-24 6:58 ` KAMEZAWA Hiroyuki
[not found] ` <20090824155835.94f6b88f.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2009-08-24 7:17 ` Balbir Singh
[not found] ` <20090824071757.GQ29572-SINUvgVNF2CyUtPGxGje5AC/G2K4zDHf@public.gmane.org>
2009-08-24 7:18 ` KAMEZAWA Hiroyuki
[not found] ` <20090824161825.c40a85a2.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2009-08-25 9:46 ` Balbir Singh
2009-08-24 0:48 ` Krzysztof Taraszka
2009-08-24 0:58 ` Krzysztof Taraszka
[not found] ` <4A924D11.80002@free.fr>
[not found] ` <ac1c4bf20908240125q1e126cdq2d2b7659ca167d52@mail.gmail.com>
[not found] ` <4A924F5C.1000208@fr.ibm.com>
[not found] ` <ac1c4bf20908240138l67cfabfcid2bb7224a1f6ab24@mail.gmail.com>
[not found] ` <4A925794.7050808@free.fr>
[not found] ` <ac1c4bf20908240245ydbc1b9bxacfcf2398049505c@mail.gmail.com>
[not found] ` <4A92676A.1080609@free.fr>
[not found] ` <4A92676A.1080609-GANU6spQydw@public.gmane.org>
2009-08-24 10:58 ` Krzysztof Taraszka
[not found] ` <ac1c4bf20908240327u424bd021t8848cf1cafb24ada@mail.gmail.com>
[not found] ` <ac1c4bf20908240327u424bd021t8848cf1cafb24ada-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-08-24 11:13 ` Daniel Lezcano
[not found] ` <4A9275CB.7030108-GANU6spQydw@public.gmane.org>
2009-08-24 11:31 ` Krzysztof Taraszka
[not found] ` <ac1c4bf20908240431p1fda5a15qd26629618397696-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-08-24 14:11 ` Daniel Lezcano
[not found] ` <4A929F83.80207-GANU6spQydw@public.gmane.org>
2009-08-24 16:26 ` Krzysztof Taraszka
[not found] ` <ac1c4bf20908240926j401003dft11f50d3be1466f90-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-08-24 16:30 ` Daniel Lezcano
[not found] ` <4A92C01E.5010809-GANU6spQydw@public.gmane.org>
2009-08-24 16:36 ` Krzysztof Taraszka
[not found] ` <ac1c4bf20908240936t1bee38e3h9388298f435f056c-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-08-24 19:22 ` Krzysztof Taraszka
[not found] ` <ac1c4bf20908241222w127f9f7em5175213281491a8d-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-08-24 23:03 ` Krzysztof Taraszka
2009-08-26 1:43 ` KAMEZAWA Hiroyuki
[not found] ` <20090826104312.97ff028f.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2009-08-26 12:11 ` Daniel Lezcano
[not found] ` <4A952689.9020704-GANU6spQydw@public.gmane.org>
2009-08-26 13:50 ` Krzysztof Taraszka
[not found] ` <ac1c4bf20908260650x3311d5d3q44631a30205089b7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-08-26 23:25 ` Krzysztof Taraszka
[not found] ` <ac1c4bf20908261625g71dff96cu77190056540cbb7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-08-28 9:32 ` Daniel Lezcano
[not found] ` <4A97A448.5050506-GANU6spQydw@public.gmane.org>
2009-08-30 23:56 ` KAMEZAWA Hiroyuki
[not found] ` <20090831085606.b7207a76.kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
2009-08-31 9:24 ` Daniel Lezcano
[not found] ` <4A9B96B7.9060009-GANU6spQydw@public.gmane.org>
2009-08-31 10:02 ` Dietmar Maurer
2009-08-31 13:40 ` Serge E. Hallyn
[not found] ` <20090831134045.GD4837-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-08-31 14:41 ` Daniel Lezcano
[not found] ` <4A9BE134.5040804-GANU6spQydw@public.gmane.org>
2009-08-31 14:54 ` Serge E. Hallyn
[not found] ` <20090831145423.GA8107-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-08-31 15:18 ` Daniel Lezcano
[not found] ` <4A9BE9A9.1080907-GANU6spQydw@public.gmane.org>
2009-08-31 15:47 ` Daniel Lezcano
2009-08-31 16:31 ` Serge E. Hallyn
[not found] ` <20090831163114.GA13896-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-09-01 18:37 ` Daniel Lezcano
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.