Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp292723ybx; Wed, 6 Nov 2019 17:13:41 -0800 (PST) X-Google-Smtp-Source: APXvYqw1n+mwZtDwSoc091elyaNRKTeV0Pz8emhXLRJINMRC/DZpv4ci0AerEIzZgCRfw1vcyZe4 X-Received: by 2002:a17:906:b24c:: with SMTP id ce12mr606663ejb.282.1573089221869; Wed, 06 Nov 2019 17:13:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573089221; cv=none; d=google.com; s=arc-20160816; b=rl/+iJSeRmQkEdi+BZJyBytCfbcQkaIN/mOkzK9XiJ6TWpuILCFGC9PBjSUUIUWTgA wKIliewt42xZEKvRRCMvAZbDZiOdD2/Oxjaf/9OcC5IUKbXF6y6GvNJNDVUmHYqC89u9 NpO53u6Bg2uodP7g0HoEegbriKaEvt2ivojr7vxcdzDXchDrH3Cvzb1RXnMP9r9iRcKD qnaHXxjPhQLIgvpsEfAoDxJqFeD9FTWIn4hyK8dpPyaykuu+CVxhC7pvCB8/sI8vh54X 29ikzs1npf8+AcGyxbM9leAvRqw9WK5gtdkQ9Rsf+fP5qGSf8PU8GBK2zQ3mQ2aoarAN IZKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=kYzJNbIs0O9a8dPgX0R29N35kZPtuAANCvpSCPAwGWc=; b=xkjGfmDXxCZ9Y4tlqmOn5RMIZpiOxWcjPPI9RNIoIdTiMvAK3TnjS7UXnV7dJr1IFf TS+Cu+cvANWVtFsmFxDIntv8oaACSZFG3XuVdUeC9rE5iGh6JAoghvhDsqGBdZFfG8At 6NbtuNMqaLHQFR0Lb7nyzxahPv+cTL/ll1Z1Ke7O/SBakSznRdyQGkS3RSHpdrQ6kzpG xvQkt54Sr7ORHbzcQMmO2o/ux8THKp6G1p47P0DquajM+AsTD4ffJ9CXwwkUVLG2WIIy B0HchiuFaQFsYzAHsiRuk72khtlcQhCRI9tfWci/ahYGEPZsJmh4KGOTJkrZYQQmfT/2 fCMQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=gIByO5nF; 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 ck4si414750ejb.29.2019.11.06.17.13.18; Wed, 06 Nov 2019 17:13:41 -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; dkim=pass header.i=@linux-foundation.org header.s=google header.b=gIByO5nF; 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 S1732640AbfKGBLg (ORCPT + 99 others); Wed, 6 Nov 2019 20:11:36 -0500 Received: from mail-lj1-f195.google.com ([209.85.208.195]:37563 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725989AbfKGBLg (ORCPT ); Wed, 6 Nov 2019 20:11:36 -0500 Received: by mail-lj1-f195.google.com with SMTP id l20so316682lje.4 for ; Wed, 06 Nov 2019 17:11:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kYzJNbIs0O9a8dPgX0R29N35kZPtuAANCvpSCPAwGWc=; b=gIByO5nFUKaSU/PpIZE6gMaLdyUfcKBOsp22xIL7XQAtKXEsAu84aBWKAefFC7n3Cx 4oJTqrxjc+3i7v8IuyG2wJAIOUl+AAQ/9qA8e7kGRh9fmgpAL8vhTDTxQ7LbYIb7VaKE e50qm4JqsB6MFzM+IqvPwzndOuDKYHHc18Gnk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kYzJNbIs0O9a8dPgX0R29N35kZPtuAANCvpSCPAwGWc=; b=qPZKFfHUg2vKKtnjTTM5G3gJ5bbtclgosDe/07E/NLj9NtUAqhMvuBUZ4Z691sZmOz v0WzHXxpK0crXGlSxO+tLvFIy5LWIghChBBPB7XWFUnLWaAZPoxOMj9KGFrHLXsW+vcT MFw2uMjcCYI9JikwltoGB7KhKc/D6ExtnLpF9HMIkLWygP9gKSU4gECp6lBYndhBxOiT rl2NKngfASLxxX+b/EZv/mTbs7/l8j6XJ21uuLtaphzkYu0+bRHfVDsEZqyh5BzGFWu/ xUogXzpZUb4qJ1xBd1oqRWRQhhB6D/jKrqI20sDN7TIbVTEpaPX/2v7haDDDRTzropx+ Y+yw== X-Gm-Message-State: APjAAAVrP9qvPq4Tct8PzQJvfgCbCEEqFRu9U/gxJb0v1+/6YYuqgsKc zK8HW3B2wVGpom7o95z++rxsO+pxWSo= X-Received: by 2002:a2e:6c03:: with SMTP id h3mr250721ljc.86.1573089093854; Wed, 06 Nov 2019 17:11:33 -0800 (PST) Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com. [209.85.208.177]) by smtp.gmail.com with ESMTPSA id f25sm215188lfm.26.2019.11.06.17.11.32 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Nov 2019 17:11:32 -0800 (PST) Received: by mail-lj1-f177.google.com with SMTP id v8so309376ljh.5 for ; Wed, 06 Nov 2019 17:11:32 -0800 (PST) X-Received: by 2002:a2e:8809:: with SMTP id x9mr249100ljh.82.1573089091962; Wed, 06 Nov 2019 17:11:31 -0800 (PST) MIME-Version: 1.0 References: <20191106193459.581614484@linutronix.de> <20191106202806.241007755@linutronix.de> In-Reply-To: <20191106202806.241007755@linutronix.de> From: Linus Torvalds Date: Wed, 6 Nov 2019 17:11:15 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [patch 5/9] x86/ioport: Reduce ioperm impact for sane usage further To: Thomas Gleixner Cc: LKML , "the arch/x86 maintainers" , Stephen Hemminger , Willy Tarreau , Juergen Gross , Sean Christopherson , "H. Peter Anvin" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 6, 2019 at 12:57 PM Thomas Gleixner wrote: > > Calculate both the position of the first zero bit and the last zero bit to > limit the range which needs to be copied. This does not solve the problem > when the previous tasked had only byte 0 cleared and the next one has only > byte 65535 cleared, but trying to solve that would be too complex and > heavyweight for the context switch path. As the ioperm() usage is very rare > the case which is optimized is the single task/process which uses ioperm(). Hmm. I may read this patch wrong, but from what I can tell, if we really have just one process with an io bitmap, we're doing unnecessary copies. If we really have just one process that has an iobitmap, I think we could just keep the bitmap of that process entirely unchanged. Then, when we switch away from it, we set the io_bitmap_base to an invalid base outside the TSS segment, and when we switch back, we set it back to the valid one. No actual bitmap copies at all. So I think that rather than the "begin/end offset" games, we should perhaps have a "what was the last process that used the IO bitmap for this TSS" pointer (and, I think, some sequence counter, so that when the process updates its bitmap, it invalidates that case)? Of course, you can do *nboth*, but if we really think that the common case is "one special process", then I think the begin/end offset is useless, but a "last bitmap process" would be very useful. Am I missing something? Linus