From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752777AbbIPI5z (ORCPT <rfc822;w@1wt.eu>);
	Wed, 16 Sep 2015 04:57:55 -0400
Received: from e06smtp07.uk.ibm.com ([195.75.94.103]:45116 "EHLO
	e06smtp07.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752686AbbIPI5w (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 16 Sep 2015 04:57:52 -0400
X-Helo: d06dlp02.portsmouth.uk.ibm.com
X-MailFrom: borntraeger@de.ibm.com
X-RcptTo: linux-kernel@vger.kernel.org
Subject: Re: [4.2] commit d59cfc09c32 (sched, cgroup: replace
 signal_struct->group_rwsem with a global percpu_rwsem) causes regression for
 libvirt/kvm
To: Paolo Bonzini <pbonzini@redhat.com>, paulmck@linux.vnet.ibm.com
References: <55F8097A.7000206@de.ibm.com>
 <20150915130550.GC16853@twins.programming.kicks-ass.net>
 <55F81EE2.4090708@de.ibm.com> <55F84A6B.1010207@redhat.com>
 <20150915173836.GO4029@linux.vnet.ibm.com> <55F92904.4090206@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>, Tejun Heo <tj@kernel.org>,
        Ingo Molnar <mingo@redhat.com>,
        "linux-kernel@vger.kernel.org >> Linux Kernel Mailing List" 
	<linux-kernel@vger.kernel.org>,
        KVM list <kvm@vger.kernel.org>, Oleg Nesterov <oleg@redhat.com>
From: Christian Borntraeger <borntraeger@de.ibm.com>
Message-ID: <55F92F04.1040706@de.ibm.com>
Date: Wed, 16 Sep 2015 10:57:40 +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: <55F92904.4090206@redhat.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-TM-AS-MML: disable
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 15091608-0029-0000-0000-000004239C44
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Am 16.09.2015 um 10:32 schrieb Paolo Bonzini:
> 
> 
> On 15/09/2015 19:38, Paul E. McKenney wrote:
>> Excellent points!
>>
>> Other options in such situations include the following:
>>
>> o	Rework so that the code uses call_rcu*() instead of *_expedited().
>>
>> o	Maintain a per-task or per-CPU counter so that every so many
>> 	*_expedited() invocations instead uses the non-expedited
>> 	counterpart.  (For example, synchronize_rcu instead of
>> 	synchronize_rcu_expedited().)
> 
> Or just use ratelimit (untested):

One of my tests was to always replace synchronize_sched_expedited with 
synchronize_sched and things turned out to be even worse. Not sure if
it makes sense to test yopur in-the-middle approach?

Christian