From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752452AbcHLTOO (ORCPT ); Fri, 12 Aug 2016 15:14:14 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:54154 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750708AbcHLTON (ORCPT ); Fri, 12 Aug 2016 15:14:13 -0400 X-IBM-Helo: d03dlp02.boulder.ibm.com X-IBM-MailFrom: paulmck@linux.vnet.ibm.com Date: Fri, 12 Aug 2016 12:14:11 -0700 From: "Paul E. McKenney" To: Rik van Riel Cc: Jouni Malinen , Thomas Gleixner , LKML , Ingo Molnar , Peter Zijlstra , Frederic Weisbecker , Chris Mason , Arjan van de Ven , rt@linutronix.de, George Spelvin , Len Brown , Josh Triplett , Eric Dumazet Subject: Re: [patch 4 14/22] timer: Switch to a non cascading wheel Reply-To: paulmck@linux.vnet.ibm.com References: <20160704093956.299369787@linutronix.de> <20160704094342.108621834@linutronix.de> <1471024216.32433.5.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1471024216.32433.5.camel@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16081219-0008-0000-0000-0000054B5183 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00005583; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000181; SDB=6.00743781; UDB=6.00350282; IPR=6.00516318; BA=6.00004660; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00012330; XFM=3.00000011; UTC=2016-08-12 19:14:10 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16081219-0009-0000-0000-00003A30DD9D Message-Id: <20160812191411.GA12616@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-08-12_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608120207 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 12, 2016 at 01:50:16PM -0400, Rik van Riel wrote: > On Thu, 2016-08-11 at 18:21 +0300, Jouni Malinen wrote: > > On Mon, Jul 4, 2016 at 12:50 PM, Thomas Gleixner > > wrote: > > > The current timer wheel has some drawbacks: > > ... > > > > It looks like this change (commit > > 500462a9de657f86edaa102f8ab6bff7f7e43fc2 in linux.git) breaks one of > > the automated test cases I'm using to test hostapd and wpa_supplicant > > with mac80211_hwsim from the kernel. I'm not sure what exactly causes > > this (did not really expect git bisect to point to timers..), but > > this > > seems to be very reproducible for me under kvm (though, this > > apparently did not happen on another device, so I'm not completely > > sure what it is needed to reproduce) with the ap_wps_er_http_proto > > test cases failing to connect 20 TCP stream sockets to a server on > > the > > localhost. The client side is a python test script and the server is > > hostapd. The failure shows up with about the 13th of those socket > > connects failing while all others (both before and after this failed > > one) going through. > > > > Would you happen to have any idea why this commit has such a > > difference in behavior?  > > I have a vague hypothesis, more of a question actually. > > How does the new timer wheel code handle lost timer ticks? > > If a KVM guest does not run for a while, because the host > is scheduling something else, the guest generally only gets > one timer tick after the guest is scheduled back in. > > If there are multiple lost ticks, they will remain lost. > > Could that cause the new timer wheel code to skip over > timer buckets occasionally, or is this hypothesis bunk? FWIW, I do appear to be seeing more lost wakeups on current mainline than on v4.7, but not enough of a difference to get a reliable bisction in reasonable time. Thanx, Paul