[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160701081022.GM30921@twins.programming.kicks-ass.net>
Date: Fri, 1 Jul 2016 10:10:22 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Byungchul Park <byungchul.park@....com>
Cc: mingo@...nel.org, linux-kernel@...r.kernel.org, npiggin@...e.de,
walken@...gle.com, ak@...e.de, tglx@...elltoy.tec.linutronix.de
Subject: Re: [RFC 08/12] lockdep: Apply crossrelease to PG_locked lock
On Fri, Jul 01, 2016 at 08:21:21AM +0900, Byungchul Park wrote:
> On Thu, Jun 30, 2016 at 03:04:58PM +0200, Peter Zijlstra wrote:
> > On Mon, Jun 20, 2016 at 01:55:23PM +0900, Byungchul Park wrote:
> > > @@ -215,6 +219,11 @@ struct page {
> > > #ifdef LAST_CPUPID_NOT_IN_PAGE_FLAGS
> > > int _last_cpupid;
> > > #endif
> > > +
> > > +#ifdef CONFIG_LOCKDEP_PAGELOCK
> > > + struct lockdep_map map;
> > > + struct cross_lock xlock;
> > > +#endif
> > > }
> >
> > So that's 32+64=96 bytes (CONFIG_LOCK_STAT=n) added to struct page,
> > really!?
>
> Yes... I concerned it at first, but I thought it would be ok since
> CONFIG_LOCKDEP_PAGE is a debug feature.
Right, but still, that's 0.75 GB of memory on my desktop (32GB total)
just for a debug feature. It grows struct page from 1.5% to 3.9% of
total memory, that is immense.
We've avoided doing this for ptl; which was doable because typically
only a small number of pages ends up being a pagetable.
In any case, I feel PG_locked is special enough to fudge. After all, the
content of all these lockdep_map thingies would basically be the same,
which is a massive waste of space.
I still need to bend my brain around this xlock stuff, that just didn't
want to parse when I looked at it last night.
Powered by blists - more mailing lists