- On Feb 9, 2022, at 2:02 PM, Waiman Long long...@redhat.com 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 at 10:41:56AM -0800, Namhyung Kim w
- 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 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 pa
- On Feb 9, 2022, at 2:22 PM, Namhyung Kim namhy...@kernel.org wrote:
> 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
- On Feb 9, 2022, at 2:45 PM, Namhyung Kim namhy...@kernel.org 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'm also concerning dynamic allocated locks in a data structure.
>> > If we k
On Thu, Feb 10, 2022 at 09:55:27PM -0800, Namhyung Kim wrote:
> So you are ok with adding two new tracepoints, even if they are
> similar to what we already have in lockdep/lock_stat, right?
Yeah, I don't think adding tracepoints to the slowpaths of the various
locks should be a problem.
Hi Paul,
On Thu, Feb 10, 2022 at 12:10 PM Paul E. McKenney wrote:
>
> On Thu, Feb 10, 2022 at 02:27:11PM -0500, Waiman Long wrote:
> > On 2/10/22 14:14, Paul E. McKenney wrote:
> > > On Thu, Feb 10, 2022 at 10:13:53AM +0100, Peter Zijlstra wrote:
> > > > On Wed, Feb 09, 2022 at 04:32:58PM -0800,
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:
> > >
> > > > Eventually I'm mostly interested
On 2/10/22 14:14, Paul E. McKenney wrote:
On Thu, Feb 10, 2022 at 10:13:53AM +0100, 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:
Eventual
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:
> >
> > > Eventually I'm mostly interested in the contended locks only and I
> > > want to reduce the overhead
On Wed, Feb 09, 2022 at 03:17:38PM -0500, 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'm also concerning dynamic allocated lock
On 2/9/22 19:27, Namhyung Kim wrote:
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'm also concerning dynamic allo
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 be
> > easy to track contended loc
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'm also concerning dynamic allocated locks in a data
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'm also concerning dynamic allocated locks in a data structure.
If we keep the info in a hash table, we should delete it wh
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
> > lock is gone. I'm n
On 2/9/22 14:17, Mathieu Desnoyers wrote:
- On Feb 9, 2022, at 2:02 PM, Waiman Long long...@redhat.com 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 at
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 at 10:41:56AM -0800, Namhyung Kim 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 at 10:41:56AM -0800, Namhyung Kim wrote:
Eventually I'm mostly interested in the contended locks only and I
want to re
On 2/9/22 04:09, 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 be
easy to track contended locks with timing by using two t
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 be
> easy to track contended locks with timing by using two tracepoints.
So why not put in two n
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
> monitoring. The kernel has CONFIG_LO
Hello,
There have been some requests for low-overhead kernel lock contention
monitoring. The kernel has CONFIG_LOCK_STAT to provide such an infra
either via /proc/lock_stat or tracepoints directly.
However it's not light-weight and hard to be used in production. So
I'm trying to separate out th
22 matches
Mail list logo
