From: Daniel Vetter <daniel@ffwll.ch>
To: "Gupta, Sourab" <sourab.gupta@intel.com>
Cc: "Goel, Akash" <akash.goel@intel.com>,
intel-gfx <intel-gfx@lists.freedesktop.org>,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: Sysfs interface to get GFX shmem usage stats per process
Date: Thu, 4 Sep 2014 14:40:47 +0200 [thread overview]
Message-ID: <20140904124047.GI15520@phenom.ffwll.local> (raw)
In-Reply-To: <1409831603.18196.31.camel@sourabgu-desktop>
On Thu, Sep 04, 2014 at 11:52:15AM +0000, Gupta, Sourab wrote:
> On Thu, 2014-09-04 at 10:01 +0000, Daniel Vetter wrote:
> > Interface design discussions should happen in public (so that
> > non-intel people can jump in, which happens rather often for other
> > drivers actually). But at least include internal mailing lists next
> > time around. Also adding dri-devel.
> >
> > The problem I see with your approach is that "process-wise" is not a
> > solid concept with drm. We can dump information per open drm file, but
> > that file descriptor can be shared between processes. And the latest
> > generation of linux compositor protocols (like dri3) actually take
> > advantage of this.
>
> By "process-wise" sharing, do you mean the sharing of the drm file
> across different processes (having different tgid's), or is it sharing
> across the threads of a single process (having same tgid)?
> Sorry, we are not aware of the sharing of drm file across processes in
> dri3 protocols, as in android userspace, we have not come across such
> scenario. Can you please shed some light on it.
>
> In our design, we have a tgid based accounting mechanism. As long as the
> drm file is shared within the threads of the same process, its resources
> (objects and memory) are accounted together. But if the drm file is
> shared across different processes (diff tgid's), this case is still an
> open.
> Will our tgid based accounting cover the dri3 usecases also (if they
> share drm file within same tgid)?
Well in unix a file descriptor is simply not tied to a process/thread at
all, so if you expose accounting data for resources which are tied to file
descriptors then that doesn't work. E.g.
- fork inteherits all the filedescriptors from its parents, same for exec
- you can pass file descriptors explicitly between processes over unix
domain sockets (this is what dri3 does).
So if you'd use the tgid of the process that opened the file you'd account
everything to the X server with dri3. Which is not really useful.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
prev parent reply other threads:[~2014-09-04 12:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-14 13:32 [PATCH] drm/i915: Sysfs interface to get GFX shmem usage stats per process sourab.gupta
2014-08-14 13:50 ` Jani Nikula
2014-08-14 14:19 ` Akash Goel
2014-08-14 14:25 ` Daniel Vetter
2014-09-03 10:09 ` [PATCH v2] " sourab.gupta
2014-09-03 10:58 ` Daniel Vetter
2014-09-03 11:49 ` Gupta, Sourab
2014-09-03 13:09 ` Daniel Vetter
[not found] ` <1409814262.18196.18.camel@sourabgu-desktop>
[not found] ` <CAKMK7uEGo_7U9sQrx78vfBo11KkzdMEttiMdq5jiViUG2niJ3A@mail.gmail.com>
2014-09-04 11:52 ` Gupta, Sourab
2014-09-04 12:40 ` Daniel Vetter [this message]
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=20140904124047.GI15520@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=akash.goel@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=sourab.gupta@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox