Re: [RFC PATCH 0/3] um: clean up mm creation - another attempt

From: Benjamin Berg <benjamin@sipsolutions.net>
To: Anton Ivanov <anton.ivanov@cambridgegreys.com>,
	Johannes Berg <johannes@sipsolutions.net>,
	linux-um@lists.infradead.org
Subject: Re: [RFC PATCH 0/3] um: clean up mm creation - another attempt
Date: Wed, 27 Sep 2023 12:42:26 +0200	[thread overview]
Message-ID: <54b803469e63dd23d90a70fa2f356124cc230be6.camel@sipsolutions.net> (raw)
In-Reply-To: <a38bf57b-c11f-7b27-63a3-d5a4bb028819@cambridgegreys.com>

Hi,

On Wed, 2023-09-27 at 10:59 +0100, Anton Ivanov wrote:
> [SNIP]
> 
> I was just looking at all the workaround which are in place to
> prevent guest processes doing a syscall on the host. If this is
> prohibited at a higher level we should get quite a boost as all these
> PTRACE_PEEKs will become unnecessary.

Are you maybe looking at the fallback code if "local_using_sysemu" is
not set? That code should be dropped either way, we can assume
PTRACE_SYSEMU support these days, so the code in e.g. handle_trap can
be removed. I had a patch for that already.

Benjamin

> 
> >     2. Maybe we can disable/cripple page access tracking? If we
> > assume
> >        initially mark all pages as accessed by userspace (i.e.
> >        pte_mkyoung), then we avoid a minor page fault on first
> > access.
> >        Doing that will mess with page eviction though.
> >     3. Do DAX (direct_access) for files. i.e. mmap files directly
> > in the
> >        host kernel rather than through UM.
> >        With a hostfs like file system, one should be able to add an
> >        intermediate block device that maps host files to physical
> > pages,
> >        then do DAX in the FS.
> >        For disk images, the existing iomem infrastructure should be
> >        usable, this should work with any DAX enabled filesystems
> > (ext2,
> >        ext4, xfs, virtiofs, erofs).
> 
> I had some plans to do a ubd gen 2 which uses mmap and/or this. They
> are
> presently way on the backburner. We can do some of that once we push
> the new VM changes.
> 
> > 
> > Benjamin
> > 
> > > 
> > > > 2. The preemption patches work fine on top (all 3 cases). The
> > > > performance difference stays.
> > > 
> > > OK.
> > > 
> > > > 3. We do not have anything of value to add in term of
> > > > cond_resched() to the drivers :(
> > > > Most drivers are fairly simplistic with no safe points to add
> > > > this.
> > > 
> > > Yeah, not surprised by this.
> > > 
> > > > 6. Do we still need force_flush_all() in the arch_dup_mmap()?
> > > > This
> > > > works with a non-forced tlb flush
> > > > using flush_tlb_mm(mm);
> > > 
> > > Maybe not, does it make a difference though?
> > > 
> > > > 7. In all cases, UML is doing something silly.
> > > > The CPU usage while doing find -type f -exec cat {} > /dev/null
> > > > measured from outside in non-preemptive and
> > > > PREEMPT_VOLUNTARY stays around 8-15%. The UML takes a
> > > > sabbatical
> > > > for the remaining 85 instead of actually
> > > > doing work. PREEMPT is slightly better at 60, but still far
> > > > from
> > > > 100%. It just keeps going into idle and I
> > > > cannot understand why.
> > > 
> > > Is it just waiting for IO?
> > > 
> > > johannes
> > > 
> > > _______________________________________________
> > > linux-um mailing list
> > > linux-um@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-um
> > > 
> > 
> > 
> 

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um