From: "Liang, Kan" <kan.liang@intel.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
CC: Tim Chen <tim.c.chen@linux.intel.com>,
        Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@elte.hu>,
        Andi Kleen <ak@linux.intel.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        "Johannes Weiner" <hannes@cmpxchg.org>, Jan Kara <jack@suse.cz>,
        linux-mm <linux-mm@kvack.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 1/2] sched/wait: Break up long wake list walk
Thread-Topic: [PATCH 1/2] sched/wait: Break up long wake list walk
Thread-Index: AQHTFWNBYSKZKyu5OE6Y+fM96SxNwqKEIDEAgASaOPD//398AIAAsKCA
Date: Thu, 17 Aug 2017 20:18:43 +0000
Message-ID: <37D7C6CF3E00A74B8858931C1DB2F0775378761B@SHSMSX103.ccr.corp.intel.com>
References: <84c7f26182b7f4723c0fe3b34ba912a9de92b8b7.1502758114.git.tim.c.chen@linux.intel.com>
 <CA+55aFznC1wqBSfYr8=92LGqz5-F6fHMzdXoqM4aOYx8sT1Dhg@mail.gmail.com>
 <37D7C6CF3E00A74B8858931C1DB2F07753786CE9@SHSMSX103.ccr.corp.intel.com>
 <CA+55aFwzTMrZwh7TE_VeZt8gx5Syoop-kA=Xqs56=FkyakrM6g@mail.gmail.com>
In-Reply-To: <CA+55aFwzTMrZwh7TE_VeZt8gx5Syoop-kA=Xqs56=FkyakrM6g@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
dlp-product: dlpe-windows
dlp-version: 10.0.102.7
dlp-reaction: no-action
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Transfer-Encoding: 8bit
Content-Length: 2347
Lines: 75


> > Here is the wake_up_page_bit call stack when the workaround is running,
> which
> > is collected by perf record -g -a -e probe:wake_up_page_bit -- sleep 10
> 
> It's actually not really wake_up_page_bit() that is all that
> interesting, it would be more interesting to see which path it is that
> *adds* the entries.
> 
> So it's mainly wait_on_page_bit_common(), but also
> add_page_wait_queue().
> 
> Can you get that call stack instead (or in addition to)?
> 

Here is the call stack of wait_on_page_bit_common
when the queue is long (entries >1000).

# Overhead  Trace output      
# ........  ..................
#
   100.00%  (ffffffff931aefca)
            |
            ---wait_on_page_bit
               __migration_entry_wait
               migration_entry_wait
               do_swap_page
               __handle_mm_fault
               handle_mm_fault
               __do_page_fault
               do_page_fault
               page_fault
               |          
               |--21.89%--0x123a2
               |          start_thread
               |          
               |--21.64%--0x12352
               |          start_thread
               |          
               |--20.90%--_int_free
               |          |          
               |           --20.44%--0
               |          
               |--7.34%--0x127a9
               |          start_thread
               |          
               |--6.84%--0x127df
               |          start_thread
               |          
               |--6.65%--0x12205
               |          0x1206d
               |          0x11f85
               |          0x11a05
               |          0x10302
               |          |          
               |           --6.62%--0xa8ee
               |                     |          
               |                      --5.22%--0x3af5
               |                                __libc_start_main
               |          
               |--5.40%--0x1284b
               |          start_thread
               |          
               |--3.14%--0x12881
               |          start_thread
               |          
               |--3.02%--0x12773
               |          start_thread
               |          
                --2.97%--0x12815
                          start_thread

Thanks,
Kan