All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Deepak R Varma <drv@mailo.com>, David Airlie <airlied@gmail.com>,
	intel-gfx@lists.freedesktop.org,
	Saurabh Singh Sengar <ssengar@microsoft.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Praveen Kumar <kumarpraveen@linux.microsoft.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	intel-gvt-dev@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 2/2] drm/i915/gvt: Avoid full proxy f_ops for vgpu_status debug attributes
Date: Tue, 17 Jan 2023 14:29:37 -0500	[thread overview]
Message-ID: <Y8b3IRhx976Ke99X@intel.com> (raw)
In-Reply-To: <Y8TkTi+/GQwhiMvO@zhen-hp.sh.intel.com>

On Mon, Jan 16, 2023 at 01:44:46PM +0800, Zhenyu Wang wrote:
> On 2023.01.10 13:49:57 -0500, Rodrigo Vivi wrote:
> > On Wed, Jan 11, 2023 at 12:00:12AM +0530, Deepak R Varma wrote:
> > > Using DEFINE_SIMPLE_ATTRIBUTE macro with the debugfs_create_file()
> > > function adds the overhead of introducing a proxy file operation
> > > functions to wrap the original read/write inside file removal protection
> > > functions. This adds significant overhead in terms of introducing and
> > > managing the proxy factory file operations structure and function
> > > wrapping at runtime.
> > > As a replacement, a combination of DEFINE_DEBUGFS_ATTRIBUTE macro paired
> > > with debugfs_create_file_unsafe() is suggested to be used instead.  The
> > > DEFINE_DEBUGFS_ATTRIBUTE utilises debugfs_file_get() and
> > > debugfs_file_put() wrappers to protect the original read and write
> > > function calls for the debug attributes. There is no need for any
> > > runtime proxy file operations to be managed by the debugfs core.
> > > Following coccicheck make command helped identify this change:
> > > 
> > > make coccicheck M=drivers/gpu/drm/i915/ MODE=patch COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
> > > 
> > > Signed-off-by: Deepak R Varma <drv@mailo.com>
> > 
> > I believe these 2 gvt cases could be done in one patch.
> > But anyways,
> > 
> > Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > 
> > for both patches... and will leave these 2 patches for gvt folks
> > to apply. Unless they ack and I apply in the drm-intel along with the other ones.
> >
> 
> yeah, they're fine with me, feel free to apply them directly.
> 
> Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>

Unfortunately I got some conflicts when trying to apply on drm-intel-next.

We probably need a new version, and probably through gvt branches it
will be easier to handle conflicts if they appear.

> 
> thanks!
> 
> > > ---
> > >  drivers/gpu/drm/i915/gvt/debugfs.c | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gvt/debugfs.c b/drivers/gpu/drm/i915/gvt/debugfs.c
> > > index 03f081c3d9a4..baccbf1761b7 100644
> > > --- a/drivers/gpu/drm/i915/gvt/debugfs.c
> > > +++ b/drivers/gpu/drm/i915/gvt/debugfs.c
> > > @@ -165,7 +165,7 @@ static int vgpu_status_get(void *data, u64 *val)
> > >  	return 0;
> > >  }
> > >  
> > > -DEFINE_SIMPLE_ATTRIBUTE(vgpu_status_fops, vgpu_status_get, NULL, "0x%llx\n");
> > > +DEFINE_DEBUGFS_ATTRIBUTE(vgpu_status_fops, vgpu_status_get, NULL, "0x%llx\n");
> > >  
> > >  /**
> > >   * intel_gvt_debugfs_add_vgpu - register debugfs entries for a vGPU
> > > @@ -182,8 +182,8 @@ void intel_gvt_debugfs_add_vgpu(struct intel_vgpu *vgpu)
> > >  			    &vgpu_mmio_diff_fops);
> > >  	debugfs_create_file_unsafe("scan_nonprivbb", 0644, vgpu->debugfs, vgpu,
> > >  				   &vgpu_scan_nonprivbb_fops);
> > > -	debugfs_create_file("status", 0644, vgpu->debugfs, vgpu,
> > > -			    &vgpu_status_fops);
> > > +	debugfs_create_file_unsafe("status", 0644, vgpu->debugfs, vgpu,
> > > +				   &vgpu_status_fops);
> > >  }
> > >  
> > >  /**
> > > -- 
> > > 2.34.1
> > > 
> > > 
> > > 



WARNING: multiple messages have this Message-ID (diff)
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Deepak R Varma <drv@mailo.com>,
	intel-gfx@lists.freedesktop.org,
	Saurabh Singh Sengar <ssengar@microsoft.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Praveen Kumar <kumarpraveen@linux.microsoft.com>,
	intel-gvt-dev@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 2/2] drm/i915/gvt: Avoid full proxy f_ops for vgpu_status debug attributes
Date: Tue, 17 Jan 2023 14:29:37 -0500	[thread overview]
Message-ID: <Y8b3IRhx976Ke99X@intel.com> (raw)
In-Reply-To: <Y8TkTi+/GQwhiMvO@zhen-hp.sh.intel.com>

On Mon, Jan 16, 2023 at 01:44:46PM +0800, Zhenyu Wang wrote:
> On 2023.01.10 13:49:57 -0500, Rodrigo Vivi wrote:
> > On Wed, Jan 11, 2023 at 12:00:12AM +0530, Deepak R Varma wrote:
> > > Using DEFINE_SIMPLE_ATTRIBUTE macro with the debugfs_create_file()
> > > function adds the overhead of introducing a proxy file operation
> > > functions to wrap the original read/write inside file removal protection
> > > functions. This adds significant overhead in terms of introducing and
> > > managing the proxy factory file operations structure and function
> > > wrapping at runtime.
> > > As a replacement, a combination of DEFINE_DEBUGFS_ATTRIBUTE macro paired
> > > with debugfs_create_file_unsafe() is suggested to be used instead.  The
> > > DEFINE_DEBUGFS_ATTRIBUTE utilises debugfs_file_get() and
> > > debugfs_file_put() wrappers to protect the original read and write
> > > function calls for the debug attributes. There is no need for any
> > > runtime proxy file operations to be managed by the debugfs core.
> > > Following coccicheck make command helped identify this change:
> > > 
> > > make coccicheck M=drivers/gpu/drm/i915/ MODE=patch COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
> > > 
> > > Signed-off-by: Deepak R Varma <drv@mailo.com>
> > 
> > I believe these 2 gvt cases could be done in one patch.
> > But anyways,
> > 
> > Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > 
> > for both patches... and will leave these 2 patches for gvt folks
> > to apply. Unless they ack and I apply in the drm-intel along with the other ones.
> >
> 
> yeah, they're fine with me, feel free to apply them directly.
> 
> Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>

Unfortunately I got some conflicts when trying to apply on drm-intel-next.

We probably need a new version, and probably through gvt branches it
will be easier to handle conflicts if they appear.

> 
> thanks!
> 
> > > ---
> > >  drivers/gpu/drm/i915/gvt/debugfs.c | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gvt/debugfs.c b/drivers/gpu/drm/i915/gvt/debugfs.c
> > > index 03f081c3d9a4..baccbf1761b7 100644
> > > --- a/drivers/gpu/drm/i915/gvt/debugfs.c
> > > +++ b/drivers/gpu/drm/i915/gvt/debugfs.c
> > > @@ -165,7 +165,7 @@ static int vgpu_status_get(void *data, u64 *val)
> > >  	return 0;
> > >  }
> > >  
> > > -DEFINE_SIMPLE_ATTRIBUTE(vgpu_status_fops, vgpu_status_get, NULL, "0x%llx\n");
> > > +DEFINE_DEBUGFS_ATTRIBUTE(vgpu_status_fops, vgpu_status_get, NULL, "0x%llx\n");
> > >  
> > >  /**
> > >   * intel_gvt_debugfs_add_vgpu - register debugfs entries for a vGPU
> > > @@ -182,8 +182,8 @@ void intel_gvt_debugfs_add_vgpu(struct intel_vgpu *vgpu)
> > >  			    &vgpu_mmio_diff_fops);
> > >  	debugfs_create_file_unsafe("scan_nonprivbb", 0644, vgpu->debugfs, vgpu,
> > >  				   &vgpu_scan_nonprivbb_fops);
> > > -	debugfs_create_file("status", 0644, vgpu->debugfs, vgpu,
> > > -			    &vgpu_status_fops);
> > > +	debugfs_create_file_unsafe("status", 0644, vgpu->debugfs, vgpu,
> > > +				   &vgpu_status_fops);
> > >  }
> > >  
> > >  /**
> > > -- 
> > > 2.34.1
> > > 
> > > 
> > > 



WARNING: multiple messages have this Message-ID (diff)
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Saurabh Singh Sengar <ssengar@microsoft.com>,
	<dri-devel@lists.freedesktop.org>, Deepak R Varma <drv@mailo.com>,
	<intel-gvt-dev@lists.freedesktop.org>,
	<intel-gfx@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>,
	Praveen Kumar <kumarpraveen@linux.microsoft.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	"David Airlie" <airlied@gmail.com>
Subject: Re: [Intel-gfx] [PATCH 2/2] drm/i915/gvt: Avoid full proxy f_ops for vgpu_status debug attributes
Date: Tue, 17 Jan 2023 14:29:37 -0500	[thread overview]
Message-ID: <Y8b3IRhx976Ke99X@intel.com> (raw)
In-Reply-To: <Y8TkTi+/GQwhiMvO@zhen-hp.sh.intel.com>

On Mon, Jan 16, 2023 at 01:44:46PM +0800, Zhenyu Wang wrote:
> On 2023.01.10 13:49:57 -0500, Rodrigo Vivi wrote:
> > On Wed, Jan 11, 2023 at 12:00:12AM +0530, Deepak R Varma wrote:
> > > Using DEFINE_SIMPLE_ATTRIBUTE macro with the debugfs_create_file()
> > > function adds the overhead of introducing a proxy file operation
> > > functions to wrap the original read/write inside file removal protection
> > > functions. This adds significant overhead in terms of introducing and
> > > managing the proxy factory file operations structure and function
> > > wrapping at runtime.
> > > As a replacement, a combination of DEFINE_DEBUGFS_ATTRIBUTE macro paired
> > > with debugfs_create_file_unsafe() is suggested to be used instead.  The
> > > DEFINE_DEBUGFS_ATTRIBUTE utilises debugfs_file_get() and
> > > debugfs_file_put() wrappers to protect the original read and write
> > > function calls for the debug attributes. There is no need for any
> > > runtime proxy file operations to be managed by the debugfs core.
> > > Following coccicheck make command helped identify this change:
> > > 
> > > make coccicheck M=drivers/gpu/drm/i915/ MODE=patch COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
> > > 
> > > Signed-off-by: Deepak R Varma <drv@mailo.com>
> > 
> > I believe these 2 gvt cases could be done in one patch.
> > But anyways,
> > 
> > Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > 
> > for both patches... and will leave these 2 patches for gvt folks
> > to apply. Unless they ack and I apply in the drm-intel along with the other ones.
> >
> 
> yeah, they're fine with me, feel free to apply them directly.
> 
> Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>

Unfortunately I got some conflicts when trying to apply on drm-intel-next.

We probably need a new version, and probably through gvt branches it
will be easier to handle conflicts if they appear.

> 
> thanks!
> 
> > > ---
> > >  drivers/gpu/drm/i915/gvt/debugfs.c | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gvt/debugfs.c b/drivers/gpu/drm/i915/gvt/debugfs.c
> > > index 03f081c3d9a4..baccbf1761b7 100644
> > > --- a/drivers/gpu/drm/i915/gvt/debugfs.c
> > > +++ b/drivers/gpu/drm/i915/gvt/debugfs.c
> > > @@ -165,7 +165,7 @@ static int vgpu_status_get(void *data, u64 *val)
> > >  	return 0;
> > >  }
> > >  
> > > -DEFINE_SIMPLE_ATTRIBUTE(vgpu_status_fops, vgpu_status_get, NULL, "0x%llx\n");
> > > +DEFINE_DEBUGFS_ATTRIBUTE(vgpu_status_fops, vgpu_status_get, NULL, "0x%llx\n");
> > >  
> > >  /**
> > >   * intel_gvt_debugfs_add_vgpu - register debugfs entries for a vGPU
> > > @@ -182,8 +182,8 @@ void intel_gvt_debugfs_add_vgpu(struct intel_vgpu *vgpu)
> > >  			    &vgpu_mmio_diff_fops);
> > >  	debugfs_create_file_unsafe("scan_nonprivbb", 0644, vgpu->debugfs, vgpu,
> > >  				   &vgpu_scan_nonprivbb_fops);
> > > -	debugfs_create_file("status", 0644, vgpu->debugfs, vgpu,
> > > -			    &vgpu_status_fops);
> > > +	debugfs_create_file_unsafe("status", 0644, vgpu->debugfs, vgpu,
> > > +				   &vgpu_status_fops);
> > >  }
> > >  
> > >  /**
> > > -- 
> > > 2.34.1
> > > 
> > > 
> > > 



  reply	other threads:[~2023-01-17 19:29 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-10 18:29 [Intel-gfx] [PATCH 0/2] drm/i915/gvt: Avoid full proxy f_ops debug attributes Deepak R Varma
2023-01-10 18:29 ` Deepak R Varma
2023-01-10 18:29 ` Deepak R Varma
2023-01-10 18:29 ` [Intel-gfx] [PATCH 1/2] drm/i915/gvt: Avoid full proxy f_ops for scan_nonprivbb " Deepak R Varma
2023-01-10 18:29   ` Deepak R Varma
2023-01-10 18:29   ` Deepak R Varma
2023-01-10 18:30 ` [Intel-gfx] [PATCH 2/2] drm/i915/gvt: Avoid full proxy f_ops for vgpu_status " Deepak R Varma
2023-01-10 18:30   ` Deepak R Varma
2023-01-10 18:30   ` Deepak R Varma
2023-01-10 18:49   ` [Intel-gfx] " Rodrigo Vivi
2023-01-10 18:49     ` Rodrigo Vivi
2023-01-10 18:49     ` Rodrigo Vivi
2023-01-11 10:02     ` [Intel-gfx] " Rodrigo Vivi
2023-01-11 10:02       ` Rodrigo Vivi
2023-01-11 10:02       ` Rodrigo Vivi
2023-01-11 14:53       ` [Intel-gfx] " Deepak R Varma
2023-01-11 14:53         ` Deepak R Varma
2023-01-11 14:53         ` Deepak R Varma
2023-01-11 15:00         ` [Intel-gfx] " Rodrigo Vivi
2023-01-11 15:00           ` Rodrigo Vivi
2023-01-11 15:00           ` Rodrigo Vivi
2023-01-11 15:16           ` [Intel-gfx] " Deepak R Varma
2023-01-11 15:16             ` Deepak R Varma
2023-01-11 15:16             ` Deepak R Varma
2023-01-11 15:24             ` [Intel-gfx] " Rodrigo Vivi
2023-01-11 15:24               ` Rodrigo Vivi
2023-01-11 15:24               ` Rodrigo Vivi
2023-01-16  5:44     ` [Intel-gfx] " Zhenyu Wang
2023-01-16  5:44       ` Zhenyu Wang
2023-01-16  5:44       ` Zhenyu Wang
2023-01-17 19:29       ` Rodrigo Vivi [this message]
2023-01-17 19:29         ` [Intel-gfx] " Rodrigo Vivi
2023-01-17 19:29         ` Rodrigo Vivi
2023-01-18  4:48         ` Deepak R Varma
2023-01-18  4:48           ` Deepak R Varma
2023-01-18  4:48           ` Deepak R Varma
2023-01-18 16:44           ` Rodrigo Vivi
2023-01-18 16:44             ` Rodrigo Vivi
2023-01-18 16:44             ` Rodrigo Vivi
2023-01-19  1:26             ` Zhenyu Wang
2023-01-19  1:26               ` Zhenyu Wang
2023-01-19  1:26               ` Zhenyu Wang
2023-01-19 22:05               ` Rodrigo Vivi
2023-01-19 22:05                 ` Rodrigo Vivi
2023-01-19 22:05                 ` Rodrigo Vivi
2023-01-20  2:20                 ` Zhenyu Wang
2023-01-20  2:20                   ` Zhenyu Wang
2023-01-20  2:20                   ` Zhenyu Wang
2023-01-10 21:54 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gvt: Avoid full proxy f_ops " Patchwork
2023-01-10 22:22 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-01-11  8:09 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork

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=Y8b3IRhx976Ke99X@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=airlied@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=drv@mailo.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-gvt-dev@lists.freedesktop.org \
    --cc=kumarpraveen@linux.microsoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ssengar@microsoft.com \
    --cc=zhenyuw@linux.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 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.