All of lore.kernel.org
 help / color / mirror / Atom feed
From: Byungchul Park <byungchul.park@lge.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: peterz@infradead.org, mingo@kernel.org,
	akpm@linux-foundation.org, tglx@linutronix.de,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-block@vger.kernel.org, kernel-team@lge.com, jack@suse.cz,
	jlayton@redhat.com, viro@zeniv.linux.org.uk, hannes@cmpxchg.org,
	npiggin@gmail.com, rgoldwyn@suse.com, vbabka@suse.cz,
	pombredanne@nexb.com, vinmenon@codeaurora.org,
	gregkh@linuxfoundation.org
Subject: Re: [PATCH 1/3] lockdep: Apply crossrelease to PG_locked locks
Date: Fri, 24 Nov 2017 12:02:36 +0900	[thread overview]
Message-ID: <20171124030236.GA28999@X58A-UD3R> (raw)
In-Reply-To: <20171116130746.i642wszwvyb7q6hm@dhcp22.suse.cz>

On Thu, Nov 16, 2017 at 02:07:46PM +0100, Michal Hocko wrote:
> On Thu 16-11-17 21:48:05, Byungchul Park wrote:
> > On 11/16/2017 9:02 PM, Michal Hocko wrote:
> > > for each struct page. So you are doubling the size. Who is going to
> > > enable this config option? You are moving this to page_ext in a later
> > > patch which is a good step but it doesn't go far enough because this
> > > still consumes those resources. Is there any problem to make this
> > > kernel command line controllable? Something we do for page_owner for
> > > example?
> > 
> > Sure. I will add it.
> > 
> > > Also it would be really great if you could give us some measures about
> > > the runtime overhead. I do not expect it to be very large but this is
> > 
> > The major overhead would come from the amount of additional memory
> > consumption for 'lockdep_map's.
> 
> yes
> 
> > Do you want me to measure the overhead by the additional memory
> > consumption?
> > 
> > Or do you expect another overhead?
> 
> I would be also interested how much impact this has on performance. I do
> not expect it would be too large but having some numbers for cache cold
> parallel kbuild or other heavy page lock workloads.

Hello Michal,

I measured 'cache cold parallel kbuild' on my qemu machine. The result
varies much so I cannot confirm, but I think there's no meaningful
difference between before and after applying crossrelease to page locks.

Actually, I expect little overhead in lock_page() and unlock_page() even
after applying crossreleas to page locks, but only expect a bit overhead
by additional memory consumption for 'lockdep_map's per page.

I run the following instructions within "QEMU x86_64 4GB memory 4 cpus":

   make clean
   echo 3 > drop_caches
   time make -j4

The results are:

   # w/o page lock tracking

   At the 1st try,
   real     5m28.105s
   user     17m52.716s
   sys      3m8.871s

   At the 2nd try,
   real     5m27.023s
   user     17m50.134s
   sys      3m9.289s

   At the 3rd try,
   real     5m22.837s
   user     17m34.514s
   sys      3m8.097s

   # w/ page lock tracking

   At the 1st try,
   real     5m18.158s
   user     17m18.200s
   sys      3m8.639s

   At the 2nd try,
   real     5m19.329s
   user     17m19.982s
   sys      3m8.345s

   At the 3rd try,
   real     5m19.626s
   user     17m21.363s
   sys      3m9.869s

I think thers's no meaningful difference on my small machine.

--
Thanks,
Byungchul

WARNING: multiple messages have this Message-ID (diff)
From: Byungchul Park <byungchul.park@lge.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: peterz@infradead.org, mingo@kernel.org,
	akpm@linux-foundation.org, tglx@linutronix.de,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-block@vger.kernel.org, kernel-team@lge.com, jack@suse.cz,
	jlayton@redhat.com, viro@zeniv.linux.org.uk, hannes@cmpxchg.org,
	npiggin@gmail.com, rgoldwyn@suse.com, vbabka@suse.cz,
	pombredanne@nexb.com, vinmenon@codeaurora.org,
	gregkh@linuxfoundation.org
Subject: Re: [PATCH 1/3] lockdep: Apply crossrelease to PG_locked locks
Date: Fri, 24 Nov 2017 12:02:36 +0900	[thread overview]
Message-ID: <20171124030236.GA28999@X58A-UD3R> (raw)
In-Reply-To: <20171116130746.i642wszwvyb7q6hm@dhcp22.suse.cz>

On Thu, Nov 16, 2017 at 02:07:46PM +0100, Michal Hocko wrote:
> On Thu 16-11-17 21:48:05, Byungchul Park wrote:
> > On 11/16/2017 9:02 PM, Michal Hocko wrote:
> > > for each struct page. So you are doubling the size. Who is going to
> > > enable this config option? You are moving this to page_ext in a later
> > > patch which is a good step but it doesn't go far enough because this
> > > still consumes those resources. Is there any problem to make this
> > > kernel command line controllable? Something we do for page_owner for
> > > example?
> > 
> > Sure. I will add it.
> > 
> > > Also it would be really great if you could give us some measures about
> > > the runtime overhead. I do not expect it to be very large but this is
> > 
> > The major overhead would come from the amount of additional memory
> > consumption for 'lockdep_map's.
> 
> yes
> 
> > Do you want me to measure the overhead by the additional memory
> > consumption?
> > 
> > Or do you expect another overhead?
> 
> I would be also interested how much impact this has on performance. I do
> not expect it would be too large but having some numbers for cache cold
> parallel kbuild or other heavy page lock workloads.

Hello Michal,

I measured 'cache cold parallel kbuild' on my qemu machine. The result
varies much so I cannot confirm, but I think there's no meaningful
difference between before and after applying crossrelease to page locks.

Actually, I expect little overhead in lock_page() and unlock_page() even
after applying crossreleas to page locks, but only expect a bit overhead
by additional memory consumption for 'lockdep_map's per page.

I run the following instructions within "QEMU x86_64 4GB memory 4 cpus":

   make clean
   echo 3 > drop_caches
   time make -j4

The results are:

   # w/o page lock tracking

   At the 1st try,
   real     5m28.105s
   user     17m52.716s
   sys      3m8.871s

   At the 2nd try,
   real     5m27.023s
   user     17m50.134s
   sys      3m9.289s

   At the 3rd try,
   real     5m22.837s
   user     17m34.514s
   sys      3m8.097s

   # w/ page lock tracking

   At the 1st try,
   real     5m18.158s
   user     17m18.200s
   sys      3m8.639s

   At the 2nd try,
   real     5m19.329s
   user     17m19.982s
   sys      3m8.345s

   At the 3rd try,
   real     5m19.626s
   user     17m21.363s
   sys      3m9.869s

I think thers's no meaningful difference on my small machine.

--
Thanks,
Byungchul

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-11-24  3:02 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-16  3:14 [PATCH 0/3] lockdep/crossrelease: Apply crossrelease to page locks Byungchul Park
2017-11-16  3:14 ` Byungchul Park
2017-11-16  3:14 ` [PATCH 1/3] lockdep: Apply crossrelease to PG_locked locks Byungchul Park
2017-11-16  3:14   ` Byungchul Park
2017-11-16 12:02   ` Michal Hocko
2017-11-16 12:02     ` Michal Hocko
2017-11-16 12:48     ` Byungchul Park
2017-11-16 12:48       ` Byungchul Park
2017-11-16 13:07       ` Michal Hocko
2017-11-16 13:07         ` Michal Hocko
2017-11-24  3:02         ` Byungchul Park [this message]
2017-11-24  3:02           ` Byungchul Park
2017-11-24  8:11           ` Michal Hocko
2017-11-24  8:11             ` Michal Hocko
2017-11-24  9:38             ` Jan Kara
2017-11-24  9:38               ` Jan Kara
2017-11-16  3:14 ` [PATCH 2/3] lockdep: Apply lock_acquire(release) on __Set(__Clear)PageLocked Byungchul Park
2017-11-16  3:14   ` Byungchul Park
2017-11-16  3:14 ` [PATCH 3/3] lockdep: Move data of CONFIG_LOCKDEP_PAGELOCK from page to page_ext Byungchul Park
2017-11-16  3:14   ` Byungchul Park

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171124030236.GA28999@X58A-UD3R \
    --to=byungchul.park@lge.com \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=jack@suse.cz \
    --cc=jlayton@redhat.com \
    --cc=kernel-team@lge.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=mingo@kernel.org \
    --cc=npiggin@gmail.com \
    --cc=peterz@infradead.org \
    --cc=pombredanne@nexb.com \
    --cc=rgoldwyn@suse.com \
    --cc=tglx@linutronix.de \
    --cc=vbabka@suse.cz \
    --cc=vinmenon@codeaurora.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.