All of lore.kernel.org
 help / color / mirror / Atom feed
From: <Peter.Enderborg@sony.com>
To: <mhocko@suse.com>
Cc: <linux-kernel@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>,
	<sumit.semwal@linaro.org>, <christian.koenig@amd.com>,
	<adobriyan@gmail.com>, <akpm@linux-foundation.org>,
	<songmuchun@bytedance.com>, <guro@fb.com>, <shakeelb@google.com>,
	<neilb@suse.de>, <samitolvanen@google.com>, <rppt@kernel.org>,
	<linux-media@vger.kernel.org>, <dri-devel@lists.freedesktop.org>,
	<linaro-mm-sig@lists.linaro.org>, <willy@infradead.org>
Subject: Re: [PATCH v4] dma-buf: Add DmaBufTotal counter in meminfo
Date: Mon, 19 Apr 2021 12:41:58 +0000	[thread overview]
Message-ID: <c3f0da9c-d127-5edf-dd21-50fd5298acef@sony.com> (raw)
In-Reply-To: <YH10s/7MjxBBsjVL@dhcp22.suse.cz>

On 4/19/21 2:16 PM, Michal Hocko wrote:
> On Sat 17-04-21 12:40:32, Peter Enderborg wrote:
>> This adds a total used dma-buf memory. Details
>> can be found in debugfs, however it is not for everyone
>> and not always available. dma-buf are indirect allocated by
>> userspace. So with this value we can monitor and detect
>> userspace applications that have problems.
> The changelog would benefit from more background on why this is needed,
> and who is the primary consumer of that value.
>
> I cannot really comment on the dma-buf internals but I have two remarks.
> Documentation/filesystems/proc.rst needs an update with the counter
> explanation and secondly is this information useful for OOM situations
> analysis? If yes then show_mem should dump the value as well.
>
> From the implementation point of view, is there any reason why this
> hasn't used the existing global_node_page_state infrastructure?

I fix doc in next version.  Im not sure what you expect the commit message to include.

The function of the meminfo is: (From Documentation/filesystems/proc.rst)

"Provides information about distribution and utilization of memory."

Im not the designed of dma-buf, I think  global_node_page_state as a kernel
internal. dma-buf is a device driver that provides a function so I might be
on the outside. However I also see that it might be relevant for a OOM.
It is memory that can be freed by killing userspace processes.

The show_mem thing. Should it be a separate patch?





WARNING: multiple messages have this Message-ID (diff)
From: <Peter.Enderborg@sony.com>
To: <mhocko@suse.com>
Cc: willy@infradead.org, neilb@suse.de, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org, adobriyan@gmail.com,
	linaro-mm-sig@lists.linaro.org, shakeelb@google.com,
	rppt@kernel.org, samitolvanen@google.com,
	songmuchun@bytedance.com, linux-fsdevel@vger.kernel.org,
	akpm@linux-foundation.org, christian.koenig@amd.com, guro@fb.com,
	linux-media@vger.kernel.org
Subject: Re: [PATCH v4] dma-buf: Add DmaBufTotal counter in meminfo
Date: Mon, 19 Apr 2021 12:41:58 +0000	[thread overview]
Message-ID: <c3f0da9c-d127-5edf-dd21-50fd5298acef@sony.com> (raw)
In-Reply-To: <YH10s/7MjxBBsjVL@dhcp22.suse.cz>

On 4/19/21 2:16 PM, Michal Hocko wrote:
> On Sat 17-04-21 12:40:32, Peter Enderborg wrote:
>> This adds a total used dma-buf memory. Details
>> can be found in debugfs, however it is not for everyone
>> and not always available. dma-buf are indirect allocated by
>> userspace. So with this value we can monitor and detect
>> userspace applications that have problems.
> The changelog would benefit from more background on why this is needed,
> and who is the primary consumer of that value.
>
> I cannot really comment on the dma-buf internals but I have two remarks.
> Documentation/filesystems/proc.rst needs an update with the counter
> explanation and secondly is this information useful for OOM situations
> analysis? If yes then show_mem should dump the value as well.
>
> From the implementation point of view, is there any reason why this
> hasn't used the existing global_node_page_state infrastructure?

I fix doc in next version.  Im not sure what you expect the commit message to include.

The function of the meminfo is: (From Documentation/filesystems/proc.rst)

"Provides information about distribution and utilization of memory."

Im not the designed of dma-buf, I think  global_node_page_state as a kernel
internal. dma-buf is a device driver that provides a function so I might be
on the outside. However I also see that it might be relevant for a OOM.
It is memory that can be freed by killing userspace processes.

The show_mem thing. Should it be a separate patch?




_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2021-04-19 12:42 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-17 10:40 [PATCH v4] dma-buf: Add DmaBufTotal counter in meminfo Peter Enderborg
2021-04-17 10:40 ` Peter Enderborg
2021-04-17 10:59 ` Christian König
2021-04-17 10:59   ` Christian König
2021-04-17 11:20   ` Peter.Enderborg
2021-04-17 11:20     ` Peter.Enderborg
2021-04-17 11:54     ` Christian König
2021-04-17 11:54       ` Christian König
2021-04-17 12:13       ` Peter.Enderborg
2021-04-17 12:13         ` Peter.Enderborg
2021-04-20  8:39       ` Daniel Vetter
2021-04-20  8:39         ` Daniel Vetter
2021-04-17 13:07 ` [External] " Muchun Song
2021-04-17 13:07   ` Muchun Song
2021-04-17 13:43   ` Peter.Enderborg
2021-04-17 13:43     ` Peter.Enderborg
2021-04-17 14:21     ` Muchun Song
2021-04-17 14:21       ` Muchun Song
2021-04-17 15:03       ` Christian König
2021-04-17 15:03         ` Christian König
2021-04-19 12:16 ` Michal Hocko
2021-04-19 12:16   ` Michal Hocko
2021-04-19 12:41   ` Peter.Enderborg [this message]
2021-04-19 12:41     ` Peter.Enderborg
2021-04-19 15:00     ` Michal Hocko
2021-04-19 15:00       ` Michal Hocko
2021-04-19 15:19       ` Peter.Enderborg
2021-04-19 15:19         ` Peter.Enderborg
2021-04-19 15:44         ` Christian König
2021-04-19 15:44           ` Christian König
2021-04-19 16:11           ` Michal Hocko
2021-04-19 16:11             ` Michal Hocko
2021-04-19 16:37             ` Christian König
2021-04-19 16:37               ` Christian König
2021-04-20  7:04               ` Michal Hocko
2021-04-20  7:04                 ` Michal Hocko
2021-04-20  7:20                 ` Mike Rapoport
2021-04-20  7:20                   ` Mike Rapoport
2021-04-20  7:47                   ` Michal Hocko
2021-04-20  7:47                     ` Michal Hocko
2021-04-20  7:32                 ` Christian König
2021-04-20  7:32                   ` Christian König
2021-04-20  7:46                   ` Michal Hocko
2021-04-20  7:46                     ` Michal Hocko
2021-04-20  8:00                     ` Christian König
2021-04-20  8:00                       ` Christian König
2021-04-20  8:28                       ` Michal Hocko
2021-04-20  8:28                         ` Michal Hocko
2021-04-20  9:02                     ` Peter.Enderborg
2021-04-20  9:02                       ` Peter.Enderborg
2021-04-20  9:12                       ` Michal Hocko
2021-04-20  9:12                         ` Michal Hocko
2021-04-20  9:25                         ` Peter.Enderborg
2021-04-20  9:25                           ` Peter.Enderborg
2021-04-20 11:04                           ` Michal Hocko
2021-04-20 11:04                             ` Michal Hocko
2021-04-20 11:24                             ` Peter.Enderborg
2021-04-20 11:24                               ` Peter.Enderborg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c3f0da9c-d127-5edf-dd21-50fd5298acef@sony.com \
    --to=peter.enderborg@sony.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=guro@fb.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mhocko@suse.com \
    --cc=neilb@suse.de \
    --cc=rppt@kernel.org \
    --cc=samitolvanen@google.com \
    --cc=shakeelb@google.com \
    --cc=songmuchun@bytedance.com \
    --cc=sumit.semwal@linaro.org \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.