Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757000AbcCCHnw (ORCPT ); Thu, 3 Mar 2016 02:43:52 -0500 Received: from mail-oi0-f47.google.com ([209.85.218.47]:33116 "EHLO mail-oi0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756689AbcCCHnu (ORCPT ); Thu, 3 Mar 2016 02:43:50 -0500 MIME-Version: 1.0 In-Reply-To: <56D71BB2.5060503@suse.cz> References: <1456448282-897-1-git-send-email-iamjoonsoo.kim@lge.com> <1456448282-897-2-git-send-email-iamjoonsoo.kim@lge.com> <56D71BB2.5060503@suse.cz> Date: Thu, 3 Mar 2016 16:43:49 +0900 Message-ID: Subject: Re: [PATCH v4 2/2] mm/page_ref: add tracepoint to track down page reference manipulation From: Joonsoo Kim To: Vlastimil Babka Cc: Andrew Morton , Michal Nazarewicz , Minchan Kim , Mel Gorman , "Kirill A. Shutemov" , Sergey Senozhatsky , Steven Rostedt , Linux Memory Management List , LKML , linux-api@vger.kernel.org, Joonsoo Kim Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3055 Lines: 82 2016-03-03 1:58 GMT+09:00 Vlastimil Babka : > On 02/26/2016 01:58 AM, js1304@gmail.com wrote: >> >> From: Joonsoo Kim >> >> CMA allocation should be guaranteed to succeed by definition, but, >> unfortunately, it would be failed sometimes. It is hard to track down >> the problem, because it is related to page reference manipulation and >> we don't have any facility to analyze it. >> >> This patch adds tracepoints to track down page reference manipulation. >> With it, we can find exact reason of failure and can fix the problem. >> Following is an example of tracepoint output. (note: this example is >> stale version that printing flags as the number. Recent version will >> print it as human readable string.) >> >> Enabling this feature bloat kernel text 30 KB in my configuration. >> >> text data bss dec hex filename >> 12127327 2243616 1507328 15878271 f2487f vmlinux_disabled >> 12157208 2258880 1507328 15923416 f2f8d8 vmlinux_enabled >> > > That's not bad, and it's even configurable. Thanks for taking the extra care > about overhead since v1. > >> Note that, due to header file dependency problem between mm.h and >> tracepoint.h, this feature has to open code the static key functions >> for tracepoints. Proposed by Steven Rostedt in following link. >> >> https://lkml.org/lkml/2015/12/9/699 >> >> v3: >> o Add commit description and code comment why this patch open code >> the static key functions for tracepoints. >> o Notify that example is stale version. >> o Add "depends on TRACEPOINTS". >> >> v2: >> o Use static key of each tracepoints to avoid function call overhead >> when tracepoints are disabled. >> o Print human-readable page flag thanks to newly introduced %pgp option. >> o Add more description to Kconfig.debug. >> >> Acked-by: Michal Nazarewicz >> Signed-off-by: Joonsoo Kim > > > Acked-by: Vlastimil Babka > >> +config DEBUG_PAGE_REF >> + bool "Enable tracepoint to track down page reference manipulation" >> + depends on DEBUG_KERNEL >> + depends on TRACEPOINTS >> + ---help--- >> + This is the feature to add tracepoint for tracking down page >> reference >> + manipulation. This tracking is useful to diagnosis functional >> failure >> + due to migration failure caused by page reference mismatch. Be > > > OK. > >> + careful to turn on this feature because it could bloat some >> kernel >> + text. In my configuration, it bloats 30 KB. Although kernel text >> will >> + be bloated, there would be no runtime performance overhead if >> + tracepoint isn't enabled thanks to jump label. > > > I would just write something like: > > Enabling this feature adds about 30 KB to the kernel code, but runtime > performance overhead is virtually none until the tracepoints are actually > enabled. Okay, better! Andrew, do you want fixup patch from me or could you simply handle it? Thanks.