[PATCH 02/10] tools/include: Sync uapi/drm/i915_drm.h with the kernel sources

2024-08-06 Thread Namhyung Kim
/i915_drm.h include/uapi/drm/i915_drm.h Please see tools/include/uapi/README for details (it's in the first patch of this series). Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Namhyung Kim --- tools/include/uapi/drm/i915_drm.h

Re: [Intel-gfx] [RFC 00/12] locking: Separate lock tracepoints from lockdep/lock_stat (v1)

2022-02-10 Thread Namhyung Kim
Feb 09, 2022 at 04:32:58PM -0800, Namhyung Kim wrote: > > > > > On Wed, Feb 9, 2022 at 1:09 AM Peter Zijlstra > > > > > wrote: > > > > > > On Tue, Feb 08, 2022 at 10:41:56AM -0800, Namhyung Kim wrote: > > > > > > > > >

Re: [Intel-gfx] [RFC 00/12] locking: Separate lock tracepoints from lockdep/lock_stat (v1)

2022-02-10 Thread Namhyung Kim
On Thu, Feb 10, 2022 at 1:14 AM Peter Zijlstra wrote: > > On Wed, Feb 09, 2022 at 04:32:58PM -0800, Namhyung Kim wrote: > > On Wed, Feb 9, 2022 at 1:09 AM Peter Zijlstra wrote: > > > > > > On Tue, Feb 08, 2022 at 10:41:56AM -0800, Namhyung Kim wrote: >

Re: [Intel-gfx] [RFC 00/12] locking: Separate lock tracepoints from lockdep/lock_stat (v1)

2022-02-09 Thread Namhyung Kim
On Wed, Feb 9, 2022 at 1:09 AM Peter Zijlstra wrote: > > On Tue, Feb 08, 2022 at 10:41:56AM -0800, Namhyung Kim wrote: > > > Eventually I'm mostly interested in the contended locks only and I > > want to reduce the overhead in the fast path. By moving that, it'd

Re: [Intel-gfx] [RFC 00/12] locking: Separate lock tracepoints from lockdep/lock_stat (v1)

2022-02-09 Thread Namhyung Kim
On Wed, Feb 9, 2022 at 12:17 PM Waiman Long wrote: > > > On 2/9/22 14:45, Namhyung Kim wrote: > > On Wed, Feb 9, 2022 at 11:28 AM Mathieu Desnoyers > > wrote: > >> - On Feb 9, 2022, at 2:22 PM, Namhyung Kim namhy...@kernel.org wrote: > >>> I'

Re: [Intel-gfx] [RFC 00/12] locking: Separate lock tracepoints from lockdep/lock_stat (v1)

2022-02-09 Thread Namhyung Kim
On Wed, Feb 9, 2022 at 11:28 AM Mathieu Desnoyers wrote: > > - On Feb 9, 2022, at 2:22 PM, Namhyung Kim namhy...@kernel.org wrote: > > I'm also concerning dynamic allocated locks in a data structure. > > If we keep the info in a hash table, we should delete it when the

Re: [Intel-gfx] [PATCH 05/12] drm/i915: Protect lockdep functions with #ifdef

2022-02-09 Thread Namhyung Kim
Hello, On Wed, Feb 9, 2022 at 8:27 AM Steven Rostedt wrote: > > On Wed, 09 Feb 2022 15:49:01 +0200 > Jani Nikula wrote: > > > > Because I want to use the lockdep annotation for other purposes. > > > But the workqueue lockdep_map was defined under LOCKDEP > > > only. Please see the description i

Re: [Intel-gfx] [RFC 00/12] locking: Separate lock tracepoints from lockdep/lock_stat (v1)

2022-02-09 Thread Namhyung Kim
Hello, On Wed, Feb 9, 2022 at 11:02 AM Waiman Long wrote: > > On 2/9/22 13:29, Mathieu Desnoyers wrote: > > - On Feb 9, 2022, at 1:19 PM, Waiman Long long...@redhat.com wrote: > > > >> On 2/9/22 04:09, Peter Zijlstra wrote: > >>> On Tue, Feb 08, 2022

[Intel-gfx] [PATCH 05/12] drm/i915: Protect lockdep functions with #ifdef

2022-02-08 Thread Namhyung Kim
ly. Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Tvrtko Ursulin Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Namhyung Kim --- drivers/gpu/drm/i915/intel_wakeref.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_wakeref.c b/drivers/gpu/drm/

[Intel-gfx] [RFC RESEND 00/12] locking: Separate lock tracepoints from lockdep/lock_stat (v1.1)

2022-02-08 Thread Namhyung Kim
Heo Cc: Byungchul Park Cc: r...@vger.kernel.org Cc: cgro...@vger.kernel.org Cc: linux-bt...@vger.kernel.org Cc: intel-gfx@lists.freedesktop.org Namhyung Kim (12): locking: Pass correct outer wait type info cgroup: rstat: Make cgroup_rstat_cpu_lock name readable timer: Protect lockdep f

Re: [Intel-gfx] [PATCH 05/12] drm/i915: Protect lockdep functions with #ifdef

2022-02-08 Thread Namhyung Kim
Hello, On Tue, Feb 8, 2022 at 10:51 AM Jani Nikula wrote: > > On Tue, 08 Feb 2022, Namhyung Kim wrote: > > With upcoming lock tracepoints config, it'd define some of lockdep > > functions without enabling CONFIG_LOCKDEP actually. The existing code > > assumes those

Re: [Intel-gfx] [RFC 00/12] locking: Separate lock tracepoints from lockdep/lock_stat (v1)

2022-02-08 Thread Namhyung Kim
Oops, I used the wrong email address of Paul. Sorry about that! I'll resend with a new address soon. Thanks, Namhyung On Tue, Feb 8, 2022 at 10:42 AM Namhyung Kim wrote: > > Hello, > > There have been some requests for low-overhead kernel lock contention > monitor

[Intel-gfx] [PATCH 05/12] drm/i915: Protect lockdep functions with #ifdef

2022-02-08 Thread Namhyung Kim
ly. Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Tvrtko Ursulin Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Namhyung Kim --- drivers/gpu/drm/i915/intel_wakeref.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_wakeref.c b/drivers/gpu/drm/

[Intel-gfx] [RFC 00/12] locking: Separate lock tracepoints from lockdep/lock_stat (v1)

2022-02-08 Thread Namhyung Kim
tree at: git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git Thanks, Namhyung Cc: Thomas Gleixner Cc: Steven Rostedt Cc: Tejun Heo Cc: Byungchul Park Cc: r...@vger.kernel.org Cc: cgro...@vger.kernel.org Cc: linux-bt...@vger.kernel.org Cc: intel-gfx@lists.freedesktop.

Re: [Intel-gfx] [PATCH v8 04/12] perf tool: extend Perf tool with CAP_PERFMON capability support

2020-04-03 Thread Namhyung Kim
open for CAP_SYS_ADMIN privileged processes but CAP_SYS_ADMIN usage for > secure perf_events monitoring is discouraged with respect to CAP_PERFMON > capability. > > Signed-off-by: Alexey Budankov > Reviewed-by: James Morris Acked-by: Namhyung Kim Thanks Namhyung _

Re: [Intel-gfx] [PATCH] fs/pstore: Perform erase from a worker

2017-03-21 Thread Namhyung Kim
Hello, On Mon, Mar 20, 2017 at 10:49:16AM -0700, Kees Cook wrote: > On Fri, Mar 17, 2017 at 2:52 AM, Chris Wilson > wrote: > > In order to prevent a cyclic recursion between psi->read_mutex and the > > inode_lock, we need to move the pse->erase to a worker. > > > > [ 605.374955] ===