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


Groups > linux.kernel > #1583025

Re: swap_cluster_info lockdep splat

From Hugh Dickins <hughd@google.com>
Newsgroups linux.kernel
Subject Re: swap_cluster_info lockdep splat
Date 2017-02-17 02:50 +0100
Message-ID <tbFQl-63c-9@gated-at.bofh.it> (permalink)
References <tbmNI-1El-7@gated-at.bofh.it> <tbpVg-3Kb-21@gated-at.bofh.it> <tbzBg-2gu-7@gated-at.bofh.it> <tbA4h-2sg-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

On Thu, 16 Feb 2017, Tim Chen wrote:
> 
> > I do not understand your zest for putting wrappers around every little
> > thing, making it all harder to follow than it need be.  Here's the patch
> > I've been running with (but you have a leak somewhere, and I don't have
> > time to search out and fix it: please try sustained swapping and swapoff).
> > 
> 
> Hugh, trying to duplicate your test case.  So you were doing swapping,
> then swap off, swap on the swap device and restart swapping?

Repeated pair of make -j20 kernel builds in 700M RAM, 1.5G swap on SSD,
8 cpus; one of the builds in tmpfs, other in ext4 on loop on tmpfs file;
sizes tuned for plenty of swapping but no OOMing (it's an ancient 2.6.24
kernel I build, modern one needing a lot more space with a lot less in use).

How much of that is relevant I don't know: hopefully none of it, it's
hard to get the tunings right from scratch.  To answer your specific
question: yes, I'm not doing concurrent swapoffs in this test showing
the leak, just waiting for each of the pair of builds to complete,
then tearing down the trees, doing swapoff followed by swapon, and
starting a new pair of builds.

Sometimes it's the swapoff that fails with ENOMEM, more often it's a
fork during build that fails with ENOMEM: after 6 or 7 hours of load
(but timings show it getting slower leading up to that).  /proc/meminfo
did not give me an immediate clue, Slab didn't look surprising but
I may not have studied close enough.

I quilt-bisected it as far as the mm-swap series, good before, bad
after, but didn't manage to narrow it down further because of hitting
a presumably different issue inside the series, where swapoff ENOMEMed
much sooner (after 25 mins one time, during first iteration the next).

Hugh

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

swap_cluster_info lockdep splat Minchan Kim <minchan@kernel.org> - 2017-02-16 06:30 +0100
  Re: swap_cluster_info lockdep splat "Huang\, Ying" <ying.huang@intel.com> - 2017-02-16 08:20 +0100
  Re: swap_cluster_info lockdep splat "Huang\, Ying" <ying.huang@intel.com> - 2017-02-16 09:50 +0100
    Re: swap_cluster_info lockdep splat Hugh Dickins <hughd@google.com> - 2017-02-16 20:10 +0100
      Re: swap_cluster_info lockdep splat Tim Chen <tim.c.chen@linux.intel.com> - 2017-02-16 20:40 +0100
        Re: swap_cluster_info lockdep splat Hugh Dickins <hughd@google.com> - 2017-02-17 02:50 +0100
          Re: swap_cluster_info lockdep splat "Huang\, Ying" <ying.huang@intel.com> - 2017-02-17 03:10 +0100
            Re: swap_cluster_info lockdep splat "Huang\, Ying" <ying.huang@intel.com> - 2017-02-17 03:40 +0100
          Re: swap_cluster_info lockdep splat "Huang\, Ying" <ying.huang@intel.com> - 2017-02-17 08:40 +0100
            Re: swap_cluster_info lockdep splat Hugh Dickins <hughd@google.com> - 2017-02-17 19:50 +0100
      Re: swap_cluster_info lockdep splat Minchan Kim <minchan@kernel.org> - 2017-02-17 00:50 +0100
      Re: swap_cluster_info lockdep splat "Huang\, Ying" <ying.huang@intel.com> - 2017-02-17 01:40 +0100

csiph-web