From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DC504C35254 for ; Mon, 10 Feb 2020 19:33:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 97EFD20715 for ; Mon, 10 Feb 2020 19:33:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="N9WtQVKb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 97EFD20715 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 23EBE6B015C; Mon, 10 Feb 2020 14:33:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1EFE16B015D; Mon, 10 Feb 2020 14:33:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0DF1A6B015E; Mon, 10 Feb 2020 14:33:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id EC6EE6B015C for ; Mon, 10 Feb 2020 14:33:11 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id A320E40C0 for ; Mon, 10 Feb 2020 19:33:11 +0000 (UTC) X-FDA: 76475215782.08.fuel89_1bd17bcdaf82f X-HE-Tag: fuel89_1bd17bcdaf82f X-Filterd-Recvd-Size: 5614 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Mon, 10 Feb 2020 19:33:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581363190; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5mZ1AteLx79LtMM0QUGOO18Kvr7nQBo+058p5c3QA9Y=; b=N9WtQVKbkaLyS/CzXPiC+CfXH/sAiTYbeRK/uiBrqieWq1cNWarNxHoEuGTIAuJbT8r964 X2USa2+VJQIQBHVzc8cYH7u11d8Bx0FXSNiYqIU04XhBxqBOEhBJVsx308+UvrII0ty0en WAwSQZRXg7mWuIryxCeRsyUmv3mDvtA= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-76-T6qKRh_bM_uoqRaeiQjEDw-1; Mon, 10 Feb 2020 14:33:08 -0500 Received: by mail-wr1-f71.google.com with SMTP id c6so5515134wrm.18 for ; Mon, 10 Feb 2020 11:33:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=KMGTDJZkPMbNI+3IMfPL5+AglR9F0y1G1+wx9lx+BsI=; b=c7c+F0HeukqOsnOcC3RamvOK6cfn+lpyrHyJJv8b38xGCHkuQ2TCAZDo71QC7BqV2e jt24Rf5YpvWOZ6aMOQF35nuLjb8srFgOaq6bTQXif/2iUon0lEIcI2muA8ViOliixBQM HxYYW2HedotFiKY1N5Pv4VspkaeQLKH4AMxnaST3J14j5ye0++s2mW1mFFlWGUE/Tuma uQ2z6hmd5rfI+eAJGAsqkHx/+IZR5AOLW4+6Mz68TcYiWtLbgbl2z70LSEai2PJIQctx pagLL7MtnRIIkF4mIJzeZdHJOvKeibEtQe6blIX6WqPXmNPMW3q2ZqWaJIRCIRcyOrYn FxNg== X-Gm-Message-State: APjAAAWOzlbQx3VwKMn4o7tpBg7YPkTY/w/UHDFa38LgRW+r8K3HY2ne 2J3VxOOoEJX7xds/gBuqaCjTtzDC57ngP9IN2dkJiqtHCUwOxPg6i2U2iGljwF3/XJHcojFbemq CwEcmMjDegSo= X-Received: by 2002:a7b:c651:: with SMTP id q17mr547561wmk.5.1581363187537; Mon, 10 Feb 2020 11:33:07 -0800 (PST) X-Google-Smtp-Source: APXvYqwOFQo4U+msfHUzbyhRVj8cg0iNrOibhxMs/UaxDfGLpnaLdW3bHIUiRE0Ps7lwZNvo2fOj/g== X-Received: by 2002:a7b:c651:: with SMTP id q17mr547530wmk.5.1581363187308; Mon, 10 Feb 2020 11:33:07 -0800 (PST) Received: from [192.168.3.122] (p5B0C6A1F.dip0.t-ipconnect.de. [91.12.106.31]) by smtp.gmail.com with ESMTPSA id a16sm1803138wrx.87.2020.02.10.11.33.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Feb 2020 11:33:06 -0800 (PST) From: David Hildenbrand Mime-Version: 1.0 (1.0) Subject: Re: [PATCH 02/35] KVM: s390/interrupt: do not pin adapter interrupt pages Date: Mon, 10 Feb 2020 20:33:06 +0100 Message-Id: <567B980B-BDA5-4EF3-A96E-1542D11F2BD4@redhat.com> References: <083a3fd0-7b56-e92b-bf15-3383b7f5488b@de.ibm.com> Cc: David Hildenbrand , Janosch Frank , KVM , Cornelia Huck , Thomas Huth , Ulrich Weigand , Claudio Imbrenda , Andrea Arcangeli , linux-s390 , Michael Mueller , Vasily Gorbik , linux-mm@kvack.org, Andrew Morton In-Reply-To: <083a3fd0-7b56-e92b-bf15-3383b7f5488b@de.ibm.com> To: Christian Borntraeger X-Mailer: iPhone Mail (17C54) X-MC-Unique: T6qKRh_bM_uoqRaeiQjEDw-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > Am 10.02.2020 um 19:41 schrieb Christian Borntraeger : >=20 > =EF=BB=BF >=20 >> On 10.02.20 13:26, David Hildenbrand wrote: >>> On 07.02.20 12:39, Christian Borntraeger wrote: >>> From: Ulrich Weigand >>>=20 >>> The adapter interrupt page containing the indicator bits is currently >>> pinned. That means that a guest with many devices can pin a lot of >>> memory pages in the host. This also complicates the reference tracking >>> which is needed for memory management handling of protected virtual >>> machines. >>> We can reuse the pte notifiers to "cache" the page without pinning it. >>>=20 >>> Signed-off-by: Ulrich Weigand >>> Suggested-by: Andrea Arcangeli >>> [borntraeger@de.ibm.com: patch merging, splitting, fixing] >>> Signed-off-by: Christian Borntraeger >>> --- >>=20 >> So, instead of pinning explicitly, look up the page address, cache it, >> and glue its lifetime to the gmap table entry. When that entry is >> changed, invalidate the cached page. On re-access, look up the page >> again and register the gmap notifier for the table entry again. >=20 > I think I might want to split this into two parts. > part 1: a naive approach that always does get_user_pages_remote/put_page > part 2: do the complex caching >=20 > Ulrich mentioned that this actually could make the map/unmap a no-op as w= e > have the address and bit already in the irq route. In the end this might = be > as fast as todays pinning as we replace a list walk with a page table wal= k.=20 > Plus it would simplify the code. Will have a look if that is the case. If we could simplify that heavily, that would be awesome!