Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp6374654ybi; Wed, 29 May 2019 07:00:40 -0700 (PDT) X-Google-Smtp-Source: APXvYqy0opG0WX4pU7bePjHAQ/PjezeeEtELS0kW5vCu3gRcWpsoZt8EpVM/r9GKbUr4QyJpGa0k X-Received: by 2002:a17:90a:62cb:: with SMTP id k11mr12024236pjs.26.1559138440615; Wed, 29 May 2019 07:00:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559138440; cv=none; d=google.com; s=arc-20160816; b=sEhc9K7ZzvVI6D/P0DpAM3is1t5+PTUr8LAlmkETjxqWA7q1cn7LkZtkVCmHprOF3W A4yW0OEikswZjcDK/cTS4tINzewDSXbHOQnNvGjLNAAX6c/1WPTA1NkasEvucsCBJGG4 lpIhicnxU0n//3dUcRdZaRG2Z+mzhmOjCa+ay3PHr6Qy9LNC+0H8Tw0f14WuezZgCnlC H9yEQxJXdkzaswP85lDc+W8zkvPRgOgkqznFlMh1wugFob6kCyBdwKUQny14qMeD0RS0 TmsTTuZ6aDbn0smp1Jrw6TZq7oYD5HVpjHU3wqHZYVCfMn0UgjZi0k0NxskZwg0VtzP2 /PDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=FZWUoahUKe48sv95gn7R8aCU4TuuVPUqZsei2R9KI6A=; b=hAcUb/lsewBCBFbS0SEmqd8owAoINg4bF3S6OPAvk/xE2w3u7DFwQP+E7aV3EKAA/U Oe6s/J18UsT4HOYxYgIxTFjPU5T9bKC6cPkaBoy+Xv2njOAUlYiMaSpIfYypWZ9NGGe9 aWrZDDNLOKy+2ZsVZyhI1+b876+fWG666csYoUR4go5WZfiOdqYPUMZkPh2X7HLcW43L gYqEyVJnMGqwuDCtEz5B7lUltm1U9PjbT8KyXFcn1owZnmtLGSAFgcOQuqQzICF6a7VU QyEASgc2HfKrNJ1VZmIfgdfJCljDwDXccVuc40kRO626bZVrhtetgdR9XKVeQjpnEdVX 5Row== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id be6si13362913plb.255.2019.05.29.07.00.23; Wed, 29 May 2019 07:00:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727297AbfE2N65 (ORCPT + 99 others); Wed, 29 May 2019 09:58:57 -0400 Received: from mail.kernel.org ([198.145.29.99]:35978 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726702AbfE2N64 (ORCPT ); Wed, 29 May 2019 09:58:56 -0400 Received: from oasis.local.home (unknown [12.156.218.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id ACAB522DA7; Wed, 29 May 2019 13:58:54 +0000 (UTC) Date: Wed, 29 May 2019 09:58:52 -0400 From: Steven Rostedt To: Peter Zijlstra Cc: Daniel Bristot de Oliveira , linux-kernel@vger.kernel.org, williams@redhat.com, daniel@bristot.me, Ingo Molnar , Thomas Gleixner , "Paul E. McKenney" , Matthias Kaehlcke , "Joel Fernandes (Google)" , Frederic Weisbecker , Yangtao Li , Tommaso Cucinotta Subject: Re: [RFC 2/3] preempt_tracer: Disable IRQ while starting/stopping due to a preempt_counter change Message-ID: <20190529095852.36865060@oasis.local.home> In-Reply-To: <20190529134946.GY2623@hirez.programming.kicks-ass.net> References: <20190529083357.GF2623@hirez.programming.kicks-ass.net> <20190529102038.GO2623@hirez.programming.kicks-ass.net> <20190529083930.5541130e@oasis.local.home> <20190529131957.GV2623@hirez.programming.kicks-ass.net> <20190529094213.3e344965@oasis.local.home> <20190529134946.GY2623@hirez.programming.kicks-ass.net> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 29 May 2019 15:49:46 +0200 Peter Zijlstra wrote: > > That's basically what I was suggesting as the solution to this ;-) > > You were wanting changes to preempt_disable() and task_struct, neither > of which is required. The above only needs some per-cpu storage in the > tracer implementation. Only changes were to the trace preempt_disable() code. Which I still think needs to be done regardless to differentiate between when we are tracing preempt disable and when we are not. And no modification would need to be done to task_struct as we already have a place to add tracing flags. -- Steve