From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752707AbbIOQmZ (ORCPT ); Tue, 15 Sep 2015 12:42:25 -0400 Received: from mail-wi0-f179.google.com ([209.85.212.179]:33145 "EHLO mail-wi0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752312AbbIOQmW (ORCPT ); Tue, 15 Sep 2015 12:42:22 -0400 Subject: Re: [4.2] commit d59cfc09c32 (sched, cgroup: replace signal_struct->group_rwsem with a global percpu_rwsem) causes regression for libvirt/kvm To: Christian Borntraeger , Peter Zijlstra References: <55F8097A.7000206@de.ibm.com> <20150915130550.GC16853@twins.programming.kicks-ass.net> <55F81EE2.4090708@de.ibm.com> Cc: Tejun Heo , Ingo Molnar , "linux-kernel@vger.kernel.org >> Linux Kernel Mailing List" , KVM list , Oleg Nesterov , Paul McKenney From: Paolo Bonzini Message-ID: <55F84A6B.1010207@redhat.com> Date: Tue, 15 Sep 2015 18:42:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55F81EE2.4090708@de.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15/09/2015 15:36, Christian Borntraeger wrote: > I am wondering why the old code behaved in such fatal ways. Is there > some interaction between waiting for a reschedule in the > synchronize_sched writer and some fork code actually waiting for the > read side to get the lock together with some rescheduling going on > waiting for a lock that fork holds? lockdep does not give me an hints > so I have no clue :-( It may just be consuming too much CPU usage. kernel/rcu/tree.c warns about it: * if you are using synchronize_sched_expedited() in a loop, please * restructure your code to batch your updates, and then use a single * synchronize_sched() instead. and you may remember that in KVM we switched from RCU to SRCU exactly to avoid userspace-controlled synchronize_rcu_expedited(). In fact, I would say that any userspace-controlled call to *_expedited() is a bug waiting to happen and a bad idea---because userspace can, with little effort, end up calling it in a loop. Paolo