Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1550545 > unrolled thread

Re: [PATCH v4 0/3] perf: add support for analyzing events for containers

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v4 0/3] perf: add support for analyzing events for  containers Krister Johansen <kjlx@templeofstupid.com> - 2017-01-04 10:10 +0100
    Re: [PATCH v4 0/3] perf: add support for analyzing events for  containers Hari Bathini <hbathini@linux.vnet.ibm.com> - 2017-01-04 12:50 +0100
    Re: [PATCH v4 0/3] perf: add support for analyzing events for  containers Aravinda Prasad <aravinda@linux.vnet.ibm.com> - 2017-01-11 12:20 +0100
      Re: [PATCH v4 0/3] perf: add support for analyzing events for containers ebiederm@xmission.com (Eric W. Biederman) - 2017-01-11 15:50 +0100

#1550545 — Re: [PATCH v4 0/3] perf: add support for analyzing events for containers

On Tue, Jan 03, 2017 at 04:57:54PM +0530, Hari Bathini wrote:
> On Thursday 29 December 2016 07:11 AM, Krister Johansen wrote:
> >On Fri, Dec 16, 2016 at 12:06:55AM +0530, Hari Bathini wrote:
> >>This patch-set overcomes this limitation by using cgroup identifier as
> >>container unique identifier. A new PERF_RECORD_NAMESPACES event that
> >>records namespaces related info is introduced, from which the cgroup
> >>namespace's device & inode numbers are used as cgroup identifier. This
> >>is based on the assumption that each container is created with it's own
> >>cgroup namespace allowing assessment/analysis of multiple containers
> >>using cgroup identifier.
> >Why choose cgroups when the kernel dispenses namespace-unique
> >identifiers. Cgroup membership can be arbitrary.  Moreover, cgroup and
> 
> Agreed. But doesn't that hold for any other namespace or a combination
> of namespaces as well?

I guess that's part of my concern.  There is no container-unique
identifier on the system, since the notion of containers is a construct
of higer-level software.  You're depending on the fact that some popular
container software packages put their processes in separate cgroups.
Some of the stranger problems I've debugged with containers involve
abuses of nsenter(1) and shared subtrees.  In cases like that, if you
filter by cgroup you may miss other interfering processes that are in
one or more of the namespaces associated with the container, but not its
cgroup.  It's possible I misunderstood.  Is the cgroup id being used to
filter events, or just for display purposes?

-K

[toc] | [next] | [standalone]

#1550686

On Wednesday 04 January 2017 02:34 PM, Krister Johansen wrote:
> On Tue, Jan 03, 2017 at 04:57:54PM +0530, Hari Bathini wrote:
>> On Thursday 29 December 2016 07:11 AM, Krister Johansen wrote:
>>> On Fri, Dec 16, 2016 at 12:06:55AM +0530, Hari Bathini wrote:
>>>> This patch-set overcomes this limitation by using cgroup identifier as
>>>> container unique identifier. A new PERF_RECORD_NAMESPACES event that
>>>> records namespaces related info is introduced, from which the cgroup
>>>> namespace's device & inode numbers are used as cgroup identifier. This
>>>> is based on the assumption that each container is created with it's own
>>>> cgroup namespace allowing assessment/analysis of multiple containers
>>>> using cgroup identifier.
>>> Why choose cgroups when the kernel dispenses namespace-unique
>>> identifiers. Cgroup membership can be arbitrary.  Moreover, cgroup and
>> Agreed. But doesn't that hold for any other namespace or a combination
>> of namespaces as well?
> I guess that's part of my concern.  There is no container-unique
> identifier on the system, since the notion of containers is a construct
> of higer-level software.  You're depending on the fact that some popular
> container software packages put their processes in separate cgroups.
> Some of the stranger problems I've debugged with containers involve
> abuses of nsenter(1) and shared subtrees.  In cases like that, if you
> filter by cgroup you may miss other interfering processes that are in
> one or more of the namespaces associated with the container, but not its
> cgroup.  It's possible I misunderstood.  Is the cgroup id being used to
> filter events, or just for display purposes?

All namespaces info for all threads is captured in perf.data with
PERF_RECORD_NAMESPACES events, which can be used
for post processing. We used cgroup namespace's id in
patch 3/3 for reporting, which can be improved later..

Thanks
Hari

[toc] | [prev] | [next] | [standalone]

#1556407

On Wednesday 04 January 2017 02:34 PM, Krister Johansen wrote:
> On Tue, Jan 03, 2017 at 04:57:54PM +0530, Hari Bathini wrote:
>> On Thursday 29 December 2016 07:11 AM, Krister Johansen wrote:
>>> On Fri, Dec 16, 2016 at 12:06:55AM +0530, Hari Bathini wrote:
>>>> This patch-set overcomes this limitation by using cgroup identifier as
>>>> container unique identifier. A new PERF_RECORD_NAMESPACES event that
>>>> records namespaces related info is introduced, from which the cgroup
>>>> namespace's device & inode numbers are used as cgroup identifier. This
>>>> is based on the assumption that each container is created with it's own
>>>> cgroup namespace allowing assessment/analysis of multiple containers
>>>> using cgroup identifier.
>>> Why choose cgroups when the kernel dispenses namespace-unique
>>> identifiers. Cgroup membership can be arbitrary.  Moreover, cgroup and
>>
>> Agreed. But doesn't that hold for any other namespace or a combination
>> of namespaces as well?
> 
> I guess that's part of my concern.  There is no container-unique
> identifier on the system, since the notion of containers is a construct
> of higer-level software.  

I wish we had a container-unique identifier. A container-unique
identifier will make things a lot more better, not just for
container-aware tracing but for audit subsystem as well.

https://lwn.net/Articles/699819/#Comments

-- 
Regards,
Aravinda

[toc] | [prev] | [next] | [standalone]

#1556545 — Re: [PATCH v4 0/3] perf: add support for analyzing events for containers

Aravinda Prasad <aravinda@linux.vnet.ibm.com> writes:

> On Wednesday 04 January 2017 02:34 PM, Krister Johansen wrote:
>> On Tue, Jan 03, 2017 at 04:57:54PM +0530, Hari Bathini wrote:
>>> On Thursday 29 December 2016 07:11 AM, Krister Johansen wrote:
>>>> On Fri, Dec 16, 2016 at 12:06:55AM +0530, Hari Bathini wrote:
>>>>> This patch-set overcomes this limitation by using cgroup identifier as
>>>>> container unique identifier. A new PERF_RECORD_NAMESPACES event that
>>>>> records namespaces related info is introduced, from which the cgroup
>>>>> namespace's device & inode numbers are used as cgroup identifier. This
>>>>> is based on the assumption that each container is created with it's own
>>>>> cgroup namespace allowing assessment/analysis of multiple containers
>>>>> using cgroup identifier.
>>>> Why choose cgroups when the kernel dispenses namespace-unique
>>>> identifiers. Cgroup membership can be arbitrary.  Moreover, cgroup and
>>>
>>> Agreed. But doesn't that hold for any other namespace or a combination
>>> of namespaces as well?
>> 
>> I guess that's part of my concern.  There is no container-unique
>> identifier on the system, since the notion of containers is a construct
>> of higer-level software.  
>
> I wish we had a container-unique identifier. A container-unique
> identifier will make things a lot more better, not just for
> container-aware tracing but for audit subsystem as well.
>
> https://lwn.net/Articles/699819/#Comments

Something like the audit login id might be useful for some things, but
don't expect it to cover all containers, or all usecases so something
like that would need a more specific name than container id.

Any such identifier needs to handle the case of nested containers, and
of container migration from one system to another.

The issue generally appears to be that we have plent of ids that can
serve that purpose but there is insufficient agreement on what
constitues a container.

So at this point just no.  You quoted my technical description of why
there does not exist such a thing as a container id, and have completely
ignored the technical reasons.

Eric

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web