From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754671AbbESIRs (ORCPT ); Tue, 19 May 2015 04:17:48 -0400 Received: from www.linutronix.de ([62.245.132.108]:53153 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754604AbbESIRp (ORCPT ); Tue, 19 May 2015 04:17:45 -0400 Date: Tue, 19 May 2015 10:17:55 +0200 (CEST) From: Thomas Gleixner To: Dave Hansen cc: linux-kernel@vger.kernel.org, x86@kernel.org, dave.hansen@linux.intel.com Subject: Re: [PATCH 10/19] x86, mpx: Trace the attempts to find bounds tables In-Reply-To: <20150519062532.B3BAC40E@viggo.jf.intel.com> Message-ID: References: <20150519062528.E2D5DDFF@viggo.jf.intel.com> <20150519062532.B3BAC40E@viggo.jf.intel.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001,URIBL_BLOCKED=0.001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 18 May 2015, Dave Hansen wrote: > > From: Dave Hansen > > There are two different events being traced here. They are > doing similar things so share a trace "EVENT_CLASS" and are > presented together. > > 1. Trace when MPX is zapping pages "mpx_unmap_zap": > > When MPX can not free an entire bounds table, it will > instead try to zap unused parts of a bounds table to free > the backing memory. This decreases RSS (resident set > size) without decreasing the virtual space allocated > for bounds tables. > > 2. Trace attempts to find bounds tables "mpx_unmap_search": > > This event traces any time we go looking to unmap a > bounds table for a given virtual address range. This is > useful to ensure that the kernel actually "tried" to free > a bounds table versus times it succeeded in finding one. > > It might try and fail if it realized that a table was > shared with an adjacent VMA which is not being unmapped. > > Signed-off-by: Dave Hansen Reviewed-by: Thomas Gleixner