linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen@iki.fi>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: "Huang, Kai" <kai.huang@intel.com>,
	linux-sgx@vger.kernel.org,  linux-mm@kvack.org
Subject: Re: VMA merging updateds?
Date: Wed, 09 Oct 2024 17:03:07 +0300	[thread overview]
Message-ID: <8a696002d50823c9fefdc07db5e5d56ecf3e1c7d.camel@iki.fi> (raw)
In-Reply-To: <4ed9e4bb-5daa-4241-863d-4bbe923a7ffc@lucifer.local>

On Mon, 2024-09-30 at 09:05 +0100, Lorenzo Stoakes wrote:
> > So I get on this first and come back to this lore thread later when
> > I have some more experience on the topic.
> 
> OK cool let's revisit this when you've done that.
> 
> I think if you did want assistance from VMA merging what I delineated
> above
> is the only sensible way forward, afaict.

So I did run some tests and since a TEE (trusted execution environment)
needs in all cases idea what it expects kernel to do all TEE's need a
memory manager. Enarx is multi-arch, and in the case of SGX there is
permissions bits per page owned by the enclave, on VM based confidential
computing (such as AMD SEN-SNP) there's some other weird shenanigans but
across all arhitectures there exists a constraint, which causes the
need. I.e. whatever happens in mm in kernel side cannot simplify the
implementation.

The current implementation of Enarx does not merge but I did some
experimental change doing "munmap and mmap" dance and I don't see
any mentionable change in the benchmarks.

So I came from the wrong early assumptions and made wrong conclusions
in the first place, i.e. somehow this mmledger crate could rendered
out. Had not looked at the code base either for 1.5 years but should
have started what I've now done first in order to recall all the
consraints.

BR, Jarkko


      reply	other threads:[~2024-10-09 14:03 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-22 16:27 Jarkko Sakkinen
2024-09-22 16:35 ` Jarkko Sakkinen
2024-09-22 16:57   ` Jarkko Sakkinen
2024-09-23  7:48     ` Jarkko Sakkinen
2024-09-26  0:07       ` Huang, Kai
2024-09-26  0:33         ` Jarkko Sakkinen
2024-09-26  0:38           ` Jarkko Sakkinen
2024-09-26  0:53             ` Huang, Kai
2024-09-26  0:38           ` Huang, Kai
2024-09-26  1:47             ` Jarkko Sakkinen
2024-09-26  1:48               ` Jarkko Sakkinen
2024-09-26 10:02                 ` Jarkko Sakkinen
2024-09-27 17:39         ` Lorenzo Stoakes
2024-09-29 22:36           ` Jarkko Sakkinen
2024-09-30  8:05             ` Lorenzo Stoakes
2024-10-09 14:03               ` Jarkko Sakkinen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8a696002d50823c9fefdc07db5e5d56ecf3e1c7d.camel@iki.fi \
    --to=jarkko.sakkinen@iki.fi \
    --cc=kai.huang@intel.com \
    --cc=linux-mm@kvack.org \
    --cc=linux-sgx@vger.kernel.org \
    --cc=lorenzo.stoakes@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox