All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To: "Sumitra Sharma" <sumitraartsy@gmail.com>,
	"Ira Weiny" <ira.weiny@intel.com>,
	"Thomas Hellström (Intel)" <thomas_os@shipmail.org>
Cc: Deepak R Varma <drv@mailo.com>,
	intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org, Daniel Vetter <daniel@ffwll.ch>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	David Airlie <airlied@gmail.com>
Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: Replace kmap() with kmap_local_page()
Date: Wed, 21 Jun 2023 15:24:29 +0200	[thread overview]
Message-ID: <13316568.uLZWGnKmhe@suse> (raw)
In-Reply-To: <79e1f37f-3ffa-0195-860b-08cc890d810e@shipmail.org>

On mercoledì 21 giugno 2023 11:06:51 CEST Thomas Hellström (Intel) wrote:
> 
> I think one thing worth mentioning in the context of this patch is that
> IIRC kmap_local_page() will block offlining of the mapping CPU until
> kunmap_local(),

Migration is disabled.

> so while I haven't seen any guidelines around the usage
> of this api for long-held mappings,

It would be advisable to not use it for long term mappings, if possible. These 
"local" mappings should better be help for not too long duration. 

> I figure it's wise to keep the
> mapping duration short, or at least avoid sleeping with a
> kmap_local_page() map active.

Nothing prevents a call of preempt_disable() around the section of code 
between kmap_local_page() / kunmap_local(). If it is needed, local mappings 
could also be acquired under spinlocks and/or with disabled interrupts.

I don't know the code, however, everything cited above could be the subject of 
a subsequent patch.

Regards,

Fabio

> I figured, while page compression is probably to be considered "slow"
> it's probably not slow enough to motivate kmap() instead of
> kmap_local_page(), but if anyone feels differently, perhaps it should be
> considered.
> 
> With that said, my Reviewed-by: still stands.
> 
> /Thomas
> 




WARNING: multiple messages have this Message-ID (diff)
From: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To: "Sumitra Sharma" <sumitraartsy@gmail.com>,
	"Ira Weiny" <ira.weiny@intel.com>,
	"Thomas Hellström (Intel)" <thomas_os@shipmail.org>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	Deepak R Varma <drv@mailo.com>,
	intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org,
	Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [PATCH v2] drm/i915: Replace kmap() with kmap_local_page()
Date: Wed, 21 Jun 2023 15:24:29 +0200	[thread overview]
Message-ID: <13316568.uLZWGnKmhe@suse> (raw)
In-Reply-To: <79e1f37f-3ffa-0195-860b-08cc890d810e@shipmail.org>

On mercoledì 21 giugno 2023 11:06:51 CEST Thomas Hellström (Intel) wrote:
> 
> I think one thing worth mentioning in the context of this patch is that
> IIRC kmap_local_page() will block offlining of the mapping CPU until
> kunmap_local(),

Migration is disabled.

> so while I haven't seen any guidelines around the usage
> of this api for long-held mappings,

It would be advisable to not use it for long term mappings, if possible. These 
"local" mappings should better be help for not too long duration. 

> I figure it's wise to keep the
> mapping duration short, or at least avoid sleeping with a
> kmap_local_page() map active.

Nothing prevents a call of preempt_disable() around the section of code 
between kmap_local_page() / kunmap_local(). If it is needed, local mappings 
could also be acquired under spinlocks and/or with disabled interrupts.

I don't know the code, however, everything cited above could be the subject of 
a subsequent patch.

Regards,

Fabio

> I figured, while page compression is probably to be considered "slow"
> it's probably not slow enough to motivate kmap() instead of
> kmap_local_page(), but if anyone feels differently, perhaps it should be
> considered.
> 
> With that said, my Reviewed-by: still stands.
> 
> /Thomas
> 




WARNING: multiple messages have this Message-ID (diff)
From: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To: "Sumitra Sharma" <sumitraartsy@gmail.com>,
	"Ira Weiny" <ira.weiny@intel.com>,
	"Thomas Hellström (Intel)" <thomas_os@shipmail.org>
Cc: Jani Nikula <jani.nikula@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, Deepak R Varma <drv@mailo.com>
Subject: Re: [PATCH v2] drm/i915: Replace kmap() with kmap_local_page()
Date: Wed, 21 Jun 2023 15:24:29 +0200	[thread overview]
Message-ID: <13316568.uLZWGnKmhe@suse> (raw)
In-Reply-To: <79e1f37f-3ffa-0195-860b-08cc890d810e@shipmail.org>

On mercoledì 21 giugno 2023 11:06:51 CEST Thomas Hellström (Intel) wrote:
> 
> I think one thing worth mentioning in the context of this patch is that
> IIRC kmap_local_page() will block offlining of the mapping CPU until
> kunmap_local(),

Migration is disabled.

> so while I haven't seen any guidelines around the usage
> of this api for long-held mappings,

It would be advisable to not use it for long term mappings, if possible. These 
"local" mappings should better be help for not too long duration. 

> I figure it's wise to keep the
> mapping duration short, or at least avoid sleeping with a
> kmap_local_page() map active.

Nothing prevents a call of preempt_disable() around the section of code 
between kmap_local_page() / kunmap_local(). If it is needed, local mappings 
could also be acquired under spinlocks and/or with disabled interrupts.

I don't know the code, however, everything cited above could be the subject of 
a subsequent patch.

Regards,

Fabio

> I figured, while page compression is probably to be considered "slow"
> it's probably not slow enough to motivate kmap() instead of
> kmap_local_page(), but if anyone feels differently, perhaps it should be
> considered.
> 
> With that said, my Reviewed-by: still stands.
> 
> /Thomas
> 




  reply	other threads:[~2023-06-21 13:24 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-17 18:04 [Intel-gfx] [PATCH v2] drm/i915: Replace kmap() with kmap_local_page() Sumitra Sharma
2023-06-17 18:04 ` Sumitra Sharma
2023-06-17 18:04 ` Sumitra Sharma
2023-06-18 18:11 ` [Intel-gfx] " Ira Weiny
2023-06-18 18:11   ` Ira Weiny
2023-06-18 18:11   ` Ira Weiny
2023-06-19  7:59   ` [Intel-gfx] " Thomas Hellström (Intel)
2023-06-19  7:59     ` Thomas Hellström (Intel)
2023-06-19  7:59     ` Thomas Hellström (Intel)
2023-06-19  8:44     ` [Intel-gfx] " Tvrtko Ursulin
2023-06-19  8:44       ` Tvrtko Ursulin
2023-06-19  8:44       ` Tvrtko Ursulin
2023-06-19 15:45   ` [Intel-gfx] " Sumitra Sharma
2023-06-19 15:45     ` Sumitra Sharma
2023-06-19 15:45     ` Sumitra Sharma
2023-06-20 13:23     ` [Intel-gfx] " Ira Weiny
2023-06-20 13:23       ` Ira Weiny
2023-06-20 13:23       ` Ira Weiny
2023-06-20 18:07       ` [Intel-gfx] " Sumitra Sharma
2023-06-20 18:07         ` Sumitra Sharma
2023-06-20 18:07         ` Sumitra Sharma
2023-06-21  9:06         ` [Intel-gfx] " Thomas Hellström (Intel)
2023-06-21  9:06           ` Thomas Hellström (Intel)
2023-06-21  9:06           ` Thomas Hellström (Intel)
2023-06-21 13:24           ` Fabio M. De Francesco [this message]
2023-06-21 13:24             ` Fabio M. De Francesco
2023-06-21 13:24             ` Fabio M. De Francesco
2023-06-21 16:35           ` [Intel-gfx] " Ira Weiny
2023-06-21 16:35             ` Ira Weiny
2023-06-21 16:35             ` Ira Weiny
2023-06-21 18:51             ` [Intel-gfx] " Thomas Hellström (Intel)
2023-06-21 18:51               ` Thomas Hellström (Intel)
2023-06-21 18:51               ` Thomas Hellström (Intel)
2023-06-22  9:40               ` [Intel-gfx] " Tvrtko Ursulin
2023-06-22  9:40                 ` Tvrtko Ursulin
2023-06-22  9:40                 ` Tvrtko Ursulin
2023-06-26  9:02       ` [Intel-gfx] " Tvrtko Ursulin
2023-06-26  9:02         ` Tvrtko Ursulin
2023-06-26  9:02         ` Tvrtko Ursulin
2023-06-21  1:09 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Replace kmap() with kmap_local_page() (rev6) Patchwork
2023-06-21 22:30 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Replace kmap() with kmap_local_page() (rev7) Patchwork
2023-06-22 12:29 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2023-06-24  0:10 ` [Intel-gfx] [PATCH v2] drm/i915: Replace kmap() with kmap_local_page() Fabio M. De Francesco
2023-06-24  0:10   ` Fabio M. De Francesco
2023-06-24  0:10   ` Fabio M. De Francesco
  -- strict thread matches above, loose matches on Subject: below --
2021-12-10 23:23 [PATCH 1/7] " ira.weiny
2021-12-22  6:08 ` [Intel-gfx] [PATCH V2] " ira.weiny

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=13316568.uLZWGnKmhe@suse \
    --to=fmdefrancesco@gmail.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=ira.weiny@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=sumitraartsy@gmail.com \
    --cc=thomas_os@shipmail.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.