intel-xe.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Harish Chegondi <harish.chegondi@intel.com>
Cc: <intel-xe@lists.freedesktop.org>, <james.ausmus@intel.com>,
	<felix.j.degrood@intel.com>,  <matthew.olson@intel.com>,
	<lucas.demarchi@intel.com>
Subject: Re: [PATCH v10 4/8] drm/xe/eustall: Add support to read() and poll() EU stall data
Date: Wed, 19 Feb 2025 10:15:52 -0800	[thread overview]
Message-ID: <85tt8pol5z.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <c55e994b413f069b4ffb60cd30e749caf3bb7223.1739906138.git.harish.chegondi@intel.com>

On Tue, 18 Feb 2025 11:53:54 -0800, Harish Chegondi wrote:
>
> @@ -39,7 +40,9 @@ struct per_xecore_buf {
>  };
>
>  struct xe_eu_stall_data_stream {
> +	bool pollin;
>	bool enabled;
> +	wait_queue_head_t poll_wq;
>	size_t data_record_size;
>	size_t per_xecore_buf_size;
>	unsigned int wait_num_reports;
> @@ -47,7 +50,11 @@ struct xe_eu_stall_data_stream {
>
>	struct xe_gt *gt;
>	struct xe_bo *bo;
> +	/* Lock to protect xecore_buf */
> +	struct mutex buf_lock;

Why do we need this new lock? I thought we would just be able to use
gt->eu_stall->stream_lock? stream_lock is already taken for read(), so we
just need to take it for eu_stall_data_buf_poll()?

> @@ -357,16 +580,26 @@ static int xe_eu_stall_stream_init(struct xe_eu_stall_data_stream *stream,
>			  max_wait_num_reports);
>		return -EINVAL;
>	}
> +
> +	init_waitqueue_head(&stream->poll_wq);
> +	INIT_DELAYED_WORK(&stream->buf_poll_work, eu_stall_data_buf_poll_work_fn);
> +	mutex_init(&stream->buf_lock);
> +	stream->buf_poll_wq = alloc_ordered_workqueue("xe_eu_stall", 0);
> +	if (!stream->buf_poll_wq)
> +		return -ENOMEM;
>	stream->per_xecore_buf_size = per_xecore_buf_size;
>	stream->sampling_rate_mult = props->sampling_rate_mult;
>	stream->wait_num_reports = props->wait_num_reports;
>	stream->data_record_size = xe_eu_stall_data_record_size(gt_to_xe(gt));
>	stream->xecore_buf = kcalloc(last_xecore, sizeof(*stream->xecore_buf), GFP_KERNEL);
> -	if (!stream->xecore_buf)
> +	if (!stream->xecore_buf) {
> +		destroy_workqueue(stream->buf_poll_wq);
>		return -ENOMEM;
> +	}
>
>	ret = xe_eu_stall_data_buf_alloc(stream, last_xecore);
>	if (ret) {
> +		destroy_workqueue(stream->buf_poll_wq);
>		kfree(stream->xecore_buf);

OK, won't block on this, but error unwinding is cleaner with label's and
goto's.

Also, if stream->buf_lock is needed, mutex_destroy is also needed for error
unwinding and also during stream close.

> diff --git a/drivers/gpu/drm/xe/xe_trace.h b/drivers/gpu/drm/xe/xe_trace.h
> index d5281de04d54..1cc6bfc34ccb 100644
> --- a/drivers/gpu/drm/xe/xe_trace.h
> +++ b/drivers/gpu/drm/xe/xe_trace.h
> @@ -427,6 +427,39 @@ DEFINE_EVENT(xe_pm_runtime, xe_pm_runtime_get_ioctl,
>	     TP_ARGS(xe, caller)
>  );
>
> +TRACE_EVENT(xe_eu_stall_data_read,
> +	    TP_PROTO(u8 slice, u8 subslice,
> +		     u32 read_ptr, u32 write_ptr,
> +		     u32 read_offset, u32 write_offset,
> +		     size_t total_size),
> +	    TP_ARGS(slice, subslice, read_ptr, write_ptr,
> +		    read_offset, write_offset, total_size),
> +
> +	    TP_STRUCT__entry(__field(u8, slice)
> +			     __field(u8, subslice)
> +			     __field(u32, read_ptr)
> +			     __field(u32, write_ptr)
> +			     __field(u32, read_offset)
> +			     __field(u32, write_offset)
> +			     __field(size_t, total_size)
> +			     ),
> +
> +	    TP_fast_assign(__entry->slice = slice;
> +			   __entry->subslice = subslice;
> +			   __entry->read_ptr = read_ptr;
> +			   __entry->write_ptr = write_ptr;
> +			   __entry->read_offset = read_offset;
> +			   __entry->write_offset = write_offset;

Keep it if we need it, but do we need both the read/write ptr's and
offset's? Since offset's are the same as ptr's, but without the ms bit.

> +			   __entry->total_size = total_size;
> +			   ),
> +
> +	    TP_printk("slice:%u subslice:%u readptr:0x%x writeptr:0x%x read off:%u write off:%u size:%zu ",
> +		      __entry->slice, __entry->subslice,
> +		      __entry->read_ptr, __entry->write_ptr,
> +		      __entry->read_offset, __entry->write_offset,
> +		      __entry->total_size)
> +);
> +
>  #endif
>
>  /* This part must be outside protection */
> --
> 2.48.1
>

  reply	other threads:[~2025-02-19 18:15 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-18 19:53 [PATCH v10 0/8] Add support for EU stall sampling Harish Chegondi
2025-02-18 19:53 ` [PATCH v10 1/8] drm/xe/topology: Add a function to find the index of the last enabled DSS in a mask Harish Chegondi
2025-02-18 19:53 ` [PATCH v10 2/8] drm/xe/uapi: Introduce API for EU stall sampling Harish Chegondi
2025-02-18 23:11   ` Dixit, Ashutosh
2025-02-18 19:53 ` [PATCH v10 3/8] drm/xe/eustall: Add support to init, enable and disable " Harish Chegondi
2025-02-19 15:27   ` Dixit, Ashutosh
2025-02-18 19:53 ` [PATCH v10 4/8] drm/xe/eustall: Add support to read() and poll() EU stall data Harish Chegondi
2025-02-19 18:15   ` Dixit, Ashutosh [this message]
2025-02-19 19:43     ` Harish Chegondi
2025-02-20  7:02       ` Dixit, Ashutosh
2025-02-20 19:52         ` Dixit, Ashutosh
2025-02-20 20:02           ` Dixit, Ashutosh
2025-02-24 18:10             ` Harish Chegondi
2025-02-24 18:16               ` Dixit, Ashutosh
2025-02-24 18:29                 ` Dixit, Ashutosh
2025-02-24 18:06           ` Harish Chegondi
2025-02-18 19:53 ` [PATCH v10 5/8] drm/xe/eustall: Add support to handle dropped " Harish Chegondi
2025-02-19 18:47   ` Dixit, Ashutosh
2025-02-18 19:53 ` [PATCH v10 6/8] drm/xe/eustall: Add EU stall sampling support for Xe2 Harish Chegondi
2025-02-18 23:29   ` Dixit, Ashutosh
2025-02-18 19:53 ` [PATCH v10 7/8] drm/xe/uapi: Add a device query to get EU stall sampling information Harish Chegondi
2025-02-18 19:53 ` [PATCH v10 8/8] drm/xe/eustall: Add workaround 22016596838 which applies to PVC Harish Chegondi
2025-02-18 20:03 ` ✓ CI.Patch_applied: success for Add support for EU stall sampling Patchwork
2025-02-18 20:03 ` ✗ CI.checkpatch: warning " Patchwork
2025-02-18 20:05 ` ✓ CI.KUnit: success " Patchwork
2025-02-18 20:21 ` ✓ CI.Build: " Patchwork
2025-02-18 20:23 ` ✓ CI.Hooks: " Patchwork
2025-02-18 20:25 ` ✓ CI.checksparse: " Patchwork
2025-02-18 20:44 ` ✓ Xe.CI.BAT: " Patchwork
2025-02-19 13:14 ` ✗ Xe.CI.Full: failure " Patchwork
2025-02-19 19:27 ` [PATCH v10 0/8] " Dixit, Ashutosh

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=85tt8pol5z.wl-ashutosh.dixit@intel.com \
    --to=ashutosh.dixit@intel.com \
    --cc=felix.j.degrood@intel.com \
    --cc=harish.chegondi@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=james.ausmus@intel.com \
    --cc=lucas.demarchi@intel.com \
    --cc=matthew.olson@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;
as well as URLs for NNTP newsgroup(s).