Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1589436 > unrolled thread

Re: [PATCH v5 06/13] lockdep: Implement crossrelease feature

Started byPeter Zijlstra <peterz@infradead.org>
First post2017-02-28 14:20 +0100
Last post2017-02-28 15:10 +0100
Articles 4 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v5 06/13] lockdep: Implement crossrelease feature Peter Zijlstra <peterz@infradead.org> - 2017-02-28 14:20 +0100
    Re: [PATCH v5 06/13] lockdep: Implement crossrelease feature Byungchul Park <byungchul.park@lge.com> - 2017-02-28 14:30 +0100
      Re: [PATCH v5 06/13] lockdep: Implement crossrelease feature Peter Zijlstra <peterz@infradead.org> - 2017-02-28 14:40 +0100
        Re: [PATCH v5 06/13] lockdep: Implement crossrelease feature Byungchul Park <byungchul.park@lge.com> - 2017-02-28 15:10 +0100

#1589436 — Re: [PATCH v5 06/13] lockdep: Implement crossrelease feature

FromPeter Zijlstra <peterz@infradead.org>
Date2017-02-28 14:20 +0100
SubjectRe: [PATCH v5 06/13] lockdep: Implement crossrelease feature
Message-ID<tfPR8-4Up-21@gated-at.bofh.it>
On Wed, Jan 18, 2017 at 10:17:32PM +0900, Byungchul Park wrote:
> +#define MAX_XHLOCKS_NR 64UL

> +#ifdef CONFIG_LOCKDEP_CROSSRELEASE
> +	if (tsk->xhlocks) {
> +		void *tmp = tsk->xhlocks;
> +		/* Disable crossrelease for current */
> +		tsk->xhlocks = NULL;
> +		vfree(tmp);
> +	}
> +#endif

> +#ifdef CONFIG_LOCKDEP_CROSSRELEASE
> +	p->xhlock_idx = 0;
> +	p->xhlock_idx_soft = 0;
> +	p->xhlock_idx_hard = 0;
> +	p->xhlock_idx_nmi = 0;
> +	p->xhlocks = vzalloc(sizeof(struct hist_lock) * MAX_XHLOCKS_NR);

I don't think we need vmalloc for this now.

> +	p->work_id = 0;
> +#endif

> +#ifdef CONFIG_LOCKDEP_CROSSRELEASE
> +	if (p->xhlocks) {
> +		void *tmp = p->xhlocks;
> +		/* Diable crossrelease for current */
> +		p->xhlocks = NULL;
> +		vfree(tmp);
> +	}
> +#endif

Second instance of the same code, which would suggest using a function
for this. Also, with a function you can loose the #ifdeffery.

[toc] | [next] | [standalone]

#1589441

FromByungchul Park <byungchul.park@lge.com>
Date2017-02-28 14:30 +0100
Message-ID<tfQ0N-4XF-1@gated-at.bofh.it>
In reply to#1589436
On Tue, Feb 28, 2017 at 02:05:13PM +0100, Peter Zijlstra wrote:
> On Wed, Jan 18, 2017 at 10:17:32PM +0900, Byungchul Park wrote:
> > +#define MAX_XHLOCKS_NR 64UL
> 
> > +#ifdef CONFIG_LOCKDEP_CROSSRELEASE
> > +	if (tsk->xhlocks) {
> > +		void *tmp = tsk->xhlocks;
> > +		/* Disable crossrelease for current */
> > +		tsk->xhlocks = NULL;
> > +		vfree(tmp);
> > +	}
> > +#endif
> 
> > +#ifdef CONFIG_LOCKDEP_CROSSRELEASE
> > +	p->xhlock_idx = 0;
> > +	p->xhlock_idx_soft = 0;
> > +	p->xhlock_idx_hard = 0;
> > +	p->xhlock_idx_nmi = 0;
> > +	p->xhlocks = vzalloc(sizeof(struct hist_lock) * MAX_XHLOCKS_NR);
> 
> I don't think we need vmalloc for this now.

Really? When is a better time to do it?

I think the time creating a task is the best time to initialize it. No?

> 
> > +	p->work_id = 0;
> > +#endif
> 
> > +#ifdef CONFIG_LOCKDEP_CROSSRELEASE
> > +	if (p->xhlocks) {
> > +		void *tmp = p->xhlocks;
> > +		/* Diable crossrelease for current */
> > +		p->xhlocks = NULL;
> > +		vfree(tmp);
> > +	}
> > +#endif
> 
> Second instance of the same code, which would suggest using a function
> for this. Also, with a function you can loose the #ifdeffery.

Yes. It looks much better.

Thank you very much.

[toc] | [prev] | [next] | [standalone]

#1589453

FromPeter Zijlstra <peterz@infradead.org>
Date2017-02-28 14:40 +0100
Message-ID<tfQav-51i-41@gated-at.bofh.it>
In reply to#1589441
On Tue, Feb 28, 2017 at 10:28:20PM +0900, Byungchul Park wrote:
> On Tue, Feb 28, 2017 at 02:05:13PM +0100, Peter Zijlstra wrote:
> > On Wed, Jan 18, 2017 at 10:17:32PM +0900, Byungchul Park wrote:
> > > +#define MAX_XHLOCKS_NR 64UL
> > 
> > > +#ifdef CONFIG_LOCKDEP_CROSSRELEASE
> > > +	if (tsk->xhlocks) {
> > > +		void *tmp = tsk->xhlocks;
> > > +		/* Disable crossrelease for current */
> > > +		tsk->xhlocks = NULL;
> > > +		vfree(tmp);
> > > +	}
> > > +#endif
> > 
> > > +#ifdef CONFIG_LOCKDEP_CROSSRELEASE
> > > +	p->xhlock_idx = 0;
> > > +	p->xhlock_idx_soft = 0;
> > > +	p->xhlock_idx_hard = 0;
> > > +	p->xhlock_idx_nmi = 0;
> > > +	p->xhlocks = vzalloc(sizeof(struct hist_lock) * MAX_XHLOCKS_NR);
> > 
> > I don't think we need vmalloc for this now.
> 
> Really? When is a better time to do it?
> 
> I think the time creating a task is the best time to initialize it. No?

The place is fine, but I would use kmalloc() now (and subsequently kfree
on the other end) for the allocation. Its not _that_ large anymore,
right?

[toc] | [prev] | [next] | [standalone]

#1589484

FromByungchul Park <byungchul.park@lge.com>
Date2017-02-28 15:10 +0100
Message-ID<tfQDv-5uI-3@gated-at.bofh.it>
In reply to#1589453
On Tue, Feb 28, 2017 at 02:35:21PM +0100, Peter Zijlstra wrote:
> On Tue, Feb 28, 2017 at 10:28:20PM +0900, Byungchul Park wrote:
> > On Tue, Feb 28, 2017 at 02:05:13PM +0100, Peter Zijlstra wrote:
> > > On Wed, Jan 18, 2017 at 10:17:32PM +0900, Byungchul Park wrote:
> > > > +#define MAX_XHLOCKS_NR 64UL
> > > 
> > > > +#ifdef CONFIG_LOCKDEP_CROSSRELEASE
> > > > +	if (tsk->xhlocks) {
> > > > +		void *tmp = tsk->xhlocks;
> > > > +		/* Disable crossrelease for current */
> > > > +		tsk->xhlocks = NULL;
> > > > +		vfree(tmp);
> > > > +	}
> > > > +#endif
> > > 
> > > > +#ifdef CONFIG_LOCKDEP_CROSSRELEASE
> > > > +	p->xhlock_idx = 0;
> > > > +	p->xhlock_idx_soft = 0;
> > > > +	p->xhlock_idx_hard = 0;
> > > > +	p->xhlock_idx_nmi = 0;
> > > > +	p->xhlocks = vzalloc(sizeof(struct hist_lock) * MAX_XHLOCKS_NR);
> > > 
> > > I don't think we need vmalloc for this now.
> > 
> > Really? When is a better time to do it?
> > 
> > I think the time creating a task is the best time to initialize it. No?
> 
> The place is fine, but I would use kmalloc() now (and subsequently kfree
> on the other end) for the allocation. Its not _that_ large anymore,
> right?

Did you mean that? OK, I will do it.

Thank you.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web