/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
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:
> > > > > >
> > >
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:
>
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
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'
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
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
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
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/
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
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
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
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/
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.
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
_
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] ===
16 matches
Mail list logo