Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755802Ab1EaQkH (ORCPT ); Tue, 31 May 2011 12:40:07 -0400 Received: from jaguar.mail.utk.edu ([160.36.0.84]:58502 "EHLO jaguar.mail.utk.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751368Ab1EaQkF (ORCPT ); Tue, 31 May 2011 12:40:05 -0400 Date: Tue, 31 May 2011 12:39:37 -0400 (EDT) From: Vince Weaver To: Peter Zijlstra cc: Vince Weaver , linux-kernel@vger.kernel.org, mingo@elte.hu, paulus@samba.org, acme@redhat.com Subject: Re: perf: [patch] regression with PERF_EVENT_IOC_REFRESH In-Reply-To: <1306857173.2353.162.camel@twins> Message-ID: References: <1306182141.2497.5.camel@laptop> <1306233036.2497.15.camel@laptop> <1306578144.1200.1150.camel@twins> <1306826593.2530.7.camel@twins> <1306857173.2353.162.camel@twins> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1437 Lines: 37 On Tue, 31 May 2011, Peter Zijlstra wrote: > > IOC_REFRESH sets event->event_limit, not wakeup_events. ahh, yes. So it's a userspace "bug". The test code called a "IOC_REFRESH, 3" whenever it got signalled. It didn't distinguish between whether it was a plain overflow or if it was a ring-buffer overflow (can it distinguish?). Thus the watermark bug was confusing the user-space code into refreshing when it was not necessary. > > I'm also bisecting the other problem I mentioned, the one where overflows > > are 10x too large on 3.0-rc1. I'm at work with a Nehalem machine so the > > bisect should go faster than the bisect I had to do on an atom machine > > this weekend. > > It wouldn't be the SIGIO fix would it?, with that every overflow > generates a SIGIO, not only the poll() wakeups. And ouch at bisecting > (or even building a kernel) on an Atom, those things are horridly slow. Oh, it could be the SIGIO fix. I hadn't realized that got merged already. And yes, bisect on atom is painful, but my alternatives were a 1.7GHz P4 (with small disk, so would have been over NFS), a 600MHz G3 iBook, or an armv6 machine. So atom it was. Vince vweaver1@eecs.utk.edu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/