Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp1553151ybx; Thu, 7 Nov 2019 13:33:31 -0800 (PST) X-Google-Smtp-Source: APXvYqyUvnMf96tPIYz/cOSkq5Lv2nYgEOhGS6o5WkeJPuW2xgRFvM1I6kpNaKW5yMNnRGwTfTNp X-Received: by 2002:a50:870c:: with SMTP id i12mr6161082edb.16.1573162411706; Thu, 07 Nov 2019 13:33:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573162411; cv=none; d=google.com; s=arc-20160816; b=BpUCPH1OcdWdtsuWc2a/DEvNijtME/gu/NRrxlBSZqRrO/Tcvz61tmsSmFdCeM4GG9 gjzYpRvwrYmJUzNcVnKfC9bjetyKfgL+HNvsIQKc0UlLJZP2V2XV4DG/uulkK3RImuRQ x7h0nUvZLwhq/QJWHCXkaZPeg4usRqxTo/s8xmpaPmZE1r/4PvdSdtWckrQHs2HUDaB4 Rn0gKFG1omj9QlJFkRDLpO1xs18EmTN2CXP1IKUSJJMBxEAhEg7fsWq81SS6R6cl6snq j+2vuTqyAvMebslPiQGuLLKAAyKke+1/zvj+x/5IoRodx9n8xWWVx3e4KJoM9L/nFt2W Xfcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=7sVQ7UM23g1BqNWFlClzlfo8SZ1WDCWRjtpHn4UK/kM=; b=MTlbnmxxxJQh3xXBs1udcMbiSXgxConMYcVnx8AoJp7EXTj1mnB7ddMIK6T/puWm8+ YzZ+LK5nRhf7e5PwrRFztiynK9kjGv8/m25zu5F0UrzLzpcDUS+L/0o3I1xuWAVQJTab D4TVOX15NyQYRqu0ram+wYWTvja4gg6oVMPX47lMb9d9/ti0s7bKmYmiFTdPUNjKPM+x u94m7qYX8XbxE+8px7grs30zfgdsmTEwZhUh1TeCaAlmO3ZLyVlHtZGOlNISioseqjYB oEIaqiQmBjLfBdFjkDdFW3ahm/lokucxXgzOkd7F45+Qc70shnAEzbETRWPCK49lsbAn 3PyQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z16si1505644edx.337.2019.11.07.13.33.06; Thu, 07 Nov 2019 13:33:31 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726438AbfKGVcY (ORCPT + 99 others); Thu, 7 Nov 2019 16:32:24 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:49680 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725882AbfKGVcY (ORCPT ); Thu, 7 Nov 2019 16:32:24 -0500 Received: from p5b06da22.dip0.t-ipconnect.de ([91.6.218.34] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iSpO4-0006A0-GZ; Thu, 07 Nov 2019 22:32:16 +0100 Date: Thu, 7 Nov 2019 22:32:15 +0100 (CET) From: Thomas Gleixner To: Brian Gerst cc: Linus Torvalds , LKML , the arch/x86 maintainers , Stephen Hemminger , Willy Tarreau , Juergen Gross , Sean Christopherson , "H. Peter Anvin" Subject: Re: [patch 5/9] x86/ioport: Reduce ioperm impact for sane usage further In-Reply-To: Message-ID: References: <20191106193459.581614484@linutronix.de> <20191106202806.241007755@linutronix.de> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 7 Nov 2019, Brian Gerst wrote: > On Thu, Nov 7, 2019 at 2:54 PM Linus Torvalds > wrote: > > > > On Thu, Nov 7, 2019 at 11:24 AM Brian Gerst wrote: > > > > > > Here is a different idea: We already map the TSS virtually in > > > cpu_entry_area. Why not page-align the IO bitmap and remap it to the > > > task's bitmap on task switch? That would avoid all copying on task > > > switch. > > > > We map the tss _once_, statically, percpu, without ever changing it, > > and then we just (potentially) change a couple of fields in it on > > process switch. > > > > Your idea isn't horrible, but it would involve a TLB flush for the > > page when the io bitmap changes. Which is almost certainly more > > expensive than just copying the bitmap intelligently. > > > > Particularly since I do think that the copy can basically be done > > effectively never, assuming there really aren't multiple concurrent > > users of ioperm() (and iopl). > > There wouldn't have to be a flush on every task switch. If we make it > so that tasks that don't use a bitmap just unmap the pages in the > cpu_entry_area and set tss.io_bitmap_base to outside the segment > limit, we would only have to flush when switching from a task using > the bitmap (because the next task uses a different bitmap or we are > unmapping it). If the previous task doesn't have a bitmap the pages > in cpu_entry_area were unmapped and can't be in the TLB, so no flush > is needed. Funny. I was just debating exactly this with Peter Ziljstra over IRC :) > Going a step further, we could track which task is mapped to the > current cpu like proposed above, and only flush when a different task > needs the IO bitmap, or when the bitmap is being freed on task exit. Yes. But, we really should check what aside of DoSemu is using this still. None of my machines I checked have a single instance of ioperm()/iopl() usage. So the real question is whether it's worth the trouble or if we are just better off to copy if there is an actual user and the sequence count of the bitmap is different than the one which was active last time. Thanks, tglx