From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754168AbdGYTgV (ORCPT ); Tue, 25 Jul 2017 15:36:21 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:35385 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751526AbdGYTgS (ORCPT ); Tue, 25 Jul 2017 15:36:18 -0400 Date: Tue, 25 Jul 2017 12:36:12 -0700 From: "Paul E. McKenney" To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, mingo@kernel.org, jiangshanlai@gmail.com, dipankar@in.ibm.com, akpm@linux-foundation.org, mathieu.desnoyers@efficios.com, josh@joshtriplett.org, tglx@linutronix.de, rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com, fweisbec@gmail.com, oleg@redhat.com Subject: Re: [PATCH tip/core/rcu 4/5] sys_membarrier: Add expedited option Reply-To: paulmck@linux.vnet.ibm.com References: <20170724215758.GA12075@linux.vnet.ibm.com> <1500933497-12612-4-git-send-email-paulmck@linux.vnet.ibm.com> <20170725163318.bporqvcoodtel4a6@hirez.programming.kicks-ass.net> <20170725164900.GR3730@linux.vnet.ibm.com> <20170725165957.alykngbnrrwn3onw@hirez.programming.kicks-ass.net> <20170725171701.GS3730@linux.vnet.ibm.com> <20170725185320.uis4hxqaqlx7y7gp@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170725185320.uis4hxqaqlx7y7gp@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17072519-0048-0000-0000-000001C990DD X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007424; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000214; SDB=6.00892809; UDB=6.00446284; IPR=6.00672973; BA=6.00005492; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00016375; XFM=3.00000015; UTC=2017-07-25 19:36:15 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17072519-0049-0000-0000-0000420254C5 Message-Id: <20170725193612.GW3730@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-07-25_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-1706020000 definitions=main-1707250303 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 25, 2017 at 08:53:20PM +0200, Peter Zijlstra wrote: > On Tue, Jul 25, 2017 at 10:17:01AM -0700, Paul E. McKenney wrote: > > > > munmap() TLB invalidate is limited to those CPUs that actually ran > > > threads of their process, while this is machine wide. > > > > Or those CPUs running threads of any process mapping the underlying file > > or whatever. > > That doesn't sound right. munmap() of a shared file only invalidates > this process's map of it. > > Swapping a file page otoh will indeed touch the union of cpumasks over > all processes mapping that page. There are a lot of variations, to be sure. For whatever it is worth, the original patch that started this uses mprotect(): https://github.com/msullivan/userspace-rcu/commit/04656b468d418efbc5d934ab07954eb8395a7ab0 > > And in either case, this can span the whole machine. Plus > > there are a number of other ways for users to do on-demand full-system > > IPIs, including any number of ways to wake up large numbers of CPUs, > > including from unrelated processes. > > Which are those? I thought we significantly reduced those with the nohz > full work. Most IPI uses now first check if a CPU actually needs the IPI > before sending it IIRC. If the task being awakened is higher priority than the task currently running on a given CPU, that CPU still gets an IPI, right? Or am I completely confused? > > But I do plan to add another alternative that is limited to threads of > > the running process. I will be carrying both versions to enable those > > who have been bugging me about this to do testing. > > Sending IPIs to mm_cpumask() might be better than expedited, but I'm > still hesitant. Just because people want it doesn't mean its a good > idea. We need to weight this against the potential for abuse. > > People want userspace preempt disable, no matter how hard they want it, > they're not getting it because its a completely crap idea. Unlike userspace preempt disable, in this case we get the abuse anyway via existing mechanisms, as in they are already being abused. If we provide a mechanism for this purpose, we at least have the potential for handling the abuse, for example: o "Defanging" sys_membarrier() on systems that are sensitive to latency. For example, this patch can be defanged by booting with the rcupdate.rcu_normal=1 kernel boot parameter, which causes requests for expedited grace periods to instead use normal grace periods. o Detecting and responding to abuse. For example, perhaps if there are more than (say) 50 expedited sys_membarrier()s within a given jiffy, the excess sys_membarrier()s are non-expedited. o Batching optimizations allow large number of concurrent requests to be handled with fewer grace periods -- and both normal and expedited grace periods already do exactly this. This horse is already out, so trying to shut the gate won't be effective. Thanx, Paul