[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/arch
On Wed, Jan 10, 2018 at 19:45:26 +0100, Maxime Villard wrote:
> Le 04/01/2018 ? 15:50, Valery Ushakov a ?crit :
> > On Thu, Jan 04, 2018 at 13:36:30 +0000, Maxime Villard wrote:
> > > Module Name: src
> > > Committed By: maxv
> > > Date: Thu Jan 4 13:36:30 UTC 2018
> > >
> > > Modified Files:
> > > src/sys/arch/amd64/amd64: genassym.cf locore.S machdep.c
> > > src/sys/arch/i386/i386: genassym.cf locore.S machdep.c
> > > src/sys/arch/x86/include: cpu.h
> > > src/sys/arch/x86/x86: intr.c pmap.c sys_machdep.c
> > >
> > > Log Message:
> > > Allocate the TSS area dynamically. This way cpu_info and cpu_tss can be
> > > put in separate pages.
> > Splitting tss and cpu info speeds up NetBSD under virtualbox without
> > VT-x quite a bit as vbox traps all TSS accesses and so all the
> > same-page cpu_info accesses are also trapped, slowing things down.
> Did you actually test? And if so, did my commit really change something?
I haven't tested this commit specifically, but I did test it with a
quick hack a few years ago
I don't remember the exact numbers, but it was a lot. If memory
serves, compiling the kernel was 4x faster or something like that.
> I'm figuring out we might have had a great performance problem here: the
> cpu_info structure is allocated from kmem, which can borrow VA from the
> direct map. Since the direct map was mapped with 1GB superpages (or 2MB
> otherwise), it looks like you could get the whole gigabyte to fault all the
I don't know if that was true back in 2013 when I tested it, but as
you can see from that kludge I only pushed tss to a page of its own.
Main Index |
Thread Index |