From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753910AbcHQGvD (ORCPT ); Wed, 17 Aug 2016 02:51:03 -0400 Received: from merlin.infradead.org ([205.233.59.134]:38318 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753411AbcHQGvC (ORCPT ); Wed, 17 Aug 2016 02:51:02 -0400 Date: Wed, 17 Aug 2016 08:50:54 +0200 From: Peter Zijlstra To: robert.foss@collabora.com Cc: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, x86@kernel.org, davem@davemloft.net, yinghan@google.com, ast@fb.com, linux@rasmusvillemoes.dk, borntraeger@de.ibm.com, linux-kernel@vger.kernel.org, Ingo Molnar , Rik van Riel , Andrew Bresticker , Sameer Nanda , Filipe Brandenburger , Josh Poimboeuf Subject: Re: [PACTH v9] stacktrace: Eliminate task stack trace duplication Message-ID: <20160817065054.GO30192@twins.programming.kicks-ass.net> References: <1471389156-8306-1-git-send-email-robert.foss@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1471389156-8306-1-git-send-email-robert.foss@collabora.com> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 16, 2016 at 07:12:36PM -0400, robert.foss@collabora.com wrote: > From: Ying Han > > The problem with small dmesg ring buffer like 512k is that only limited number > of task traces will be logged. Sometimes we lose important information only > because of too many duplicated stack traces. This problem occurs when dumping > lots of stacks in a single operation, such as sysrq-T. > > This patch tries to reduce the duplication of task stack trace in the dump > message by hashing the task stack. The hashtable is a 32k pre-allocated buffer > during bootup. Each time if we find the identical task trace in the task stack, > we dump only the pid of the task which has the task trace dumped. So it is easy > to back track to the full stack with the pid. > > When we do the hashing, we eliminate garbage entries from stack traces. Those > entries are still being printed in the dump to provide more debugging > informations. > > [ 53.510162] kworker/0:0 S ffffffff8161d820 0 4 2 0x00000000 > [ 53.517237] ffff88027547de60 0000000000000046 ffffffff812ab840 0000000000000000 > [ 53.524663] ffff880275460080 ffff88027547dfd8 ffff88027547dfd8 ffff88027547dfd8 > [ 53.532092] ffffffff81813020 ffff880275460080 0000000000000000 ffff8808758670c0 > [ 53.539521] Call Trace: > [ 53.541974] [] ? cfq_init_queue+0x350/0x350 > [ 53.547791] [] schedule+0x29/0x70 > [ 53.552761] [] worker_thread+0x233/0x380 > [ 53.558318] [] ? manage_workers.isra.28+0x230/0x230 > [ 53.564839] [] kthread+0x93/0xa0 > [ 53.569714] [] kernel_thread_helper+0x4/0x10 > [ 53.575628] [] ? kthread_worker_fn+0x140/0x140 > [ 53.581714] [] ? gs_change+0xb/0xb > [ 53.586762] kworker/u:0 S ffffffff8161d820 0 5 2 0x00000000 > [ 53.593858] ffff88027547fe60 0000000000000046 ffffffffa005cc70 0000000000000000 > [ 53.601307] ffff8802754627d0 ffff88027547ffd8 ffff88027547ffd8 ffff88027547ffd8 > [ 53.608788] ffffffff81813020 ffff8802754627d0 0000000000011fc0 ffff8804758670c0 > [ 53.616232] Call Trace: > [ 53.618676] > You might want to wait a bit and have a look at this: https://lkml.kernel.org/r/cover.1471011425.git.jpoimboe@redhat.com