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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8B2EFC433F5 for ; Tue, 25 Jan 2022 12:09:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DE6BB6B007B; Tue, 25 Jan 2022 07:09:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D96DC6B007D; Tue, 25 Jan 2022 07:09:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C5ED06B0080; Tue, 25 Jan 2022 07:09:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0048.hostedemail.com [216.40.44.48]) by kanga.kvack.org (Postfix) with ESMTP id B77566B007B for ; Tue, 25 Jan 2022 07:09:06 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 7423D8249980 for ; Tue, 25 Jan 2022 12:09:06 +0000 (UTC) X-FDA: 79068688692.10.30B5B79 Received: from mail-il1-f179.google.com (mail-il1-f179.google.com [209.85.166.179]) by imf29.hostedemail.com (Postfix) with ESMTP id 1C36D120071 for ; Tue, 25 Jan 2022 12:09:05 +0000 (UTC) Received: by mail-il1-f179.google.com with SMTP id o10so16677382ilh.0 for ; Tue, 25 Jan 2022 04:09:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=oIUXCBkZfDaLwCmKVAom3m0nKZsZArvDj4sp66MxNIY=; b=kbwWYTigtVbAwxVP5h/2WoMNCT0uvDobJJOmV8gAulZTryYMbYlINIkMwhyjUfRvlm APbiDi0n5yDb7PWuT3c5q+g+YA5mcbj6tUatepXj1ktuRNxnIpCX7OYCB/9eNKfoNAlH LI6jOFVO6fG1UvjIizRiFwgZqz04lBkyIhYDYObNAXfDwZt+HUdAiYoSI3lZ7RVWDet/ FFzhe6BokKBfPG+t2TtrbnyNdc3QaY9OZ7/rwcWwQEd4vjEEAE9m4hqdA5BzSt9jHuYn wWbj1SCWgHoDjrOgWWVhA/SpFPmvg1M993W/otRzFlCRXDErqfRo9cXVBuy01+KPtsMp tnfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=oIUXCBkZfDaLwCmKVAom3m0nKZsZArvDj4sp66MxNIY=; b=B8pwL2MzoEAWuIWJOOVJFc2q3dJuDLVcfSw5hguQtDpqpTh5sEkS5XhKN/eZaAhEc2 0WXTZ81fYKPQJ1O0CLWi/2mSMokuDJo1LR9nQJIgnj0uRh9B7Y3E7DbQeBiqO8m+pxiz 3xBJD/0vaRNhsO2FQhtkEvhhRBSejd8vWU+X/ct4WJiMUZ3oFdvvouFrKOBpt6MInfoP zY0FjxNyNi0RHpDsyRlbw1BIwuvW/O9YcAKpRuYQ7IVJFYKJCAn/MBoXAldXqyeETFkX pkNGcYZmiQ+7e+EgImHalGaj2CW8MG7EIRyRC6JWrn2ucqxHnU6YYFRWfZpNDlXXOu3P DJoQ== X-Gm-Message-State: AOAM530KfnO7HtnTMQLtdo/AOoR3GkJlol4Xh6gYwLGNMOxoYz2OrOVW 1B1mIww9SO2lsK55EiSrZkc= X-Google-Smtp-Source: ABdhPJxcJRVl8Fn9/N5IAWVXaogd7+vJ+p5UHZ/wbZXPiXLLmpuscNgQLcWynu2NtESRMFJ2w3uXew== X-Received: by 2002:a92:d68b:: with SMTP id p11mr11243784iln.222.1643112544862; Tue, 25 Jan 2022 04:09:04 -0800 (PST) Received: from smtpclient.apple ([2601:285:8200:efd:d5d:bd1d:8ace:f57f]) by smtp.gmail.com with ESMTPSA id i10sm5091515ilv.86.2022.01.25.04.09.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 Jan 2022 04:09:04 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: William Kucharski Mime-Version: 1.0 (1.0) Subject: Re: [RFC PATCH 0/6] Add support for shared PTEs across processes Date: Tue, 25 Jan 2022 05:09:03 -0700 Message-Id: References: <20220125114212.ks2qtncaahi6foan@box.shutemov.name> Cc: Khalid Aziz , akpm@linux-foundation.org, willy@infradead.org, longpeng2@huawei.com, arnd@arndb.de, dave.hansen@linux.intel.com, david@redhat.com, rppt@kernel.org, surenb@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org In-Reply-To: <20220125114212.ks2qtncaahi6foan@box.shutemov.name> To: "Kirill A. Shutemov" X-Mailer: iPhone Mail (19D49) X-Stat-Signature: sdexebq8hfgchusfh6mr47yoiaaqhfcu X-Rspam-User: nil Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=kbwWYTig; spf=pass (imf29.hostedemail.com: domain of kucharsk@gmail.com designates 209.85.166.179 as permitted sender) smtp.mailfrom=kucharsk@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 1C36D120071 X-HE-Tag: 1643112545-270609 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: I would think this should be the case; certainly it seems to be a more effec= tive approach than having to manually enable sharing via the API in every ca= se or via changes to ld.so. If anything it might be useful to have an API for shutting it off, though th= ere are already multiple areas where the system shares resources in ways tha= t cannot be shut off by user action. > On Jan 25, 2022, at 04:41, Kirill A. Shutemov wrote= : >=20 > =EF=BB=BFOn Tue, Jan 18, 2022 at 02:19:12PM -0700, Khalid Aziz wrote: >> Example Code >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Snippet of the code that a donor process would run looks like below: >>=20 >> ----------------- >> addr =3D mmap((void *)TB(2), GB(512), PROT_READ | PROT_WRITE, >> MAP_SHARED | MAP_ANONYMOUS, 0, 0); >> if (addr =3D=3D MAP_FAILED) >> perror("ERROR: mmap failed"); >>=20 >> err =3D syscall(MSHARE_SYSCALL, "testregion", (void *)TB(2), >> GB(512), O_CREAT|O_RDWR|O_EXCL, 600); >> if (err < 0) { >> perror("mshare() syscall failed"); >> exit(1); >> } >>=20 >> strncpy(addr, "Some random shared text", >> sizeof("Some random shared text")); >> ----------------- >>=20 >> Snippet of code that a consumer process would execute looks like: >>=20 >> ----------------- >> fd =3D open("testregion", O_RDONLY); >> if (fd < 0) { >> perror("open failed"); >> exit(1); >> } >>=20 >> if ((count =3D read(fd, &mshare_info, sizeof(mshare_info)) > 0)) >> printf("INFO: %ld bytes shared at addr %lx \n", >> mshare_info[1], mshare_info[0]); >> else >> perror("read failed"); >>=20 >> close(fd); >>=20 >> addr =3D (char *)mshare_info[0]; >> err =3D syscall(MSHARE_SYSCALL, "testregion", (void *)mshare_info[= 0], >> mshare_info[1], O_RDWR, 600); >> if (err < 0) { >> perror("mshare() syscall failed"); >> exit(1); >> } >>=20 >> printf("Guest mmap at %px:\n", addr); >> printf("%s\n", addr); >> printf("\nDone\n"); >>=20 >> err =3D syscall(MSHARE_UNLINK_SYSCALL, "testregion"); >> if (err < 0) { >> perror("mshare_unlink() failed"); >> exit(1); >> } >> ----------------- >=20 > I wounder if we can get away with zero-API here: we can transparently > create/use shared page tables for any inode on mmap(MAP_SHARED) as long as= > size and alignment is sutiable. Page tables will be linked to the inode > and will be freed when the last of such mapping will go away. I don't see > a need in new syscalls of flags to existing one. >=20 > --=20 > Kirill A. Shutemov >=20