linux-kernel - Re: [uml-devel] [PATCH 2/2] UML

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <200703310010.34803.blaisorblade@yahoo.it>
Date:	Sat, 31 Mar 2007 00:10:34 +0200
From:	Blaisorblade <blaisorblade@...oo.it>
To:	user-mode-linux-devel@...ts.sourceforge.net
Cc:	Jeff Dike <jdike@...toit.com>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [uml-devel] [PATCH 2/2] UML - Speed up exec

On venerdì 30 marzo 2007, Jeff Dike wrote:
> flush_thread doesn't need to do a full page table walk in order to
> clear the address space.  It knows what the end result needs to be, so
> it can call unmap directly.
>
> This results in a 10-20% speedup in an exec from bash.

Oh, yeah!
When porting part of Ingo's work, I realized that a similar thing can be done 
for fork().

If the whole address space is unmapped in init_new_context_skas(), the first 
fix_range_common() call won't need to call unmap at all. He did this with 
remap_file_pages(), where init_new_context_skas() must "unmap" everything 
anyway.

This is giving some speedup in lmbench (5% better in fork proc, 2% better in 
exec proc), but the results are still controversial, there is one benchmark 
with a 2% slowdown (called 'mmap latency').

In a loop, it maps, touches a byte per page and unmaps a region with growing 
size (up to 32MB).

However, since results aren't yet stable for some other benchmark (context 
switching benchmark is crazy), I'm still studying on this.

> Signed-off-by: Jeff Dike <jdike@...ux.intel.com>
> --
>  arch/um/kernel/skas/exec.c |   12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> Index: linux-2.6.21-mm/arch/um/kernel/skas/exec.c
> ===================================================================
> --- linux-2.6.21-mm.orig/arch/um/kernel/skas/exec.c	2007-03-30
> 10:28:24.000000000 -0400 +++
> linux-2.6.21-mm/arch/um/kernel/skas/exec.c	2007-03-30 10:30:15.000000000
> -0400 @@ -17,7 +17,17 @@
>
>  void flush_thread_skas(void)
>  {
> -	force_flush_all();
> +	void *data = NULL;
> +	unsigned long end = proc_mm ? task_size : CONFIG_STUB_START;
> +	int ret;
> +
> +	ret = unmap(&current->mm->context.skas.id, 0, end, 1, &data);
> +	if(ret){
> +		printk("flush_thread_skas - clearing address space failed, "
> +		       "err = %d\n", ret);
> +		force_sig(SIGKILL, current);
> +	}
> +
>  	switch_mm_skas(&current->mm->context.skas.id);
>  }

-- 
Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade

View attachment "first-flush-optim.diff" of type "text/x-diff" (3911 bytes)