Re: [Qemu-devel] [PATCH] Rewrite mmap_find_vma() to work fine on 64-bit hosts with 32-bit targets

[Kirill A. Shutemov]

On Mon, Dec 08, 2008 at 11:42:10PM +0000, Paul Brook wrote:
> On Monday 08 December 2008, Kirill A. Shutemov wrote:
> > On Wed, Dec 03, 2008 at 02:50:57PM +0200, Kirill A. Shutemov wrote:
> > > On Wed, Dec 03, 2008 at 12:34:18PM +0000, Paul Brook wrote:
> > > > On Wednesday 03 December 2008, Kirill A. Shutemov wrote:
> > > > > qemu's page table can be incomple if /proc/self/maps is unavailable
> > > > > or host allocating a memory with mmap(), so we can't use it to find
> > > > > free memory area.
> > > >
> > > > Do we really care? Do such systems exist?
> > >
> > > I use qemu-arm to build packages in restricted environment -- in
> > > hasher[1]. hasher mounts /proc only for packages that really need it for
> > > building (java, for example).
> > >
> > > [1] http://en.altlinux.org/Hasher
> >
> > Paul, do you have any objection or not? I really want to see it into
> > upstream.
> 
> My objection is that we're replacing a fairly deterministic code that 
> maintains an address map with something that uses host mmap fairly 
> aggressively to do probing. I'm not sure this is a good thing.

In most cases we need only one probe to find hole.

Allocate 100Mb 10 times:
$ time arm-linux-user/qemu-arm ~/tmp/test 10 100000000
it takes 1 probes
it takes 1 probes
count: 10, size: 100000000
chunk 0
it takes 1 probes
0x40082000
chunk 1
it takes 1 probes
0x45fe1000
chunk 2
it takes 1 probes
0x4bf40000
chunk 3
it takes 1 probes
0x51e9f000
chunk 4
it takes 1 probes
0x57dfe000
chunk 5
it takes 21734 probes
0x63242000
chunk 6
it takes 1 probes
0x691a1000
chunk 7
it takes 1 probes
0x6f100000
chunk 8
it takes 1 probes
0x7505f000
chunk 9
it takes 1 probes
0x7afbe000
arm-linux-user/qemu-arm ~/tmp/test 10 100000000  0,01s user 0,08s system
98% cpu 0,096 total

test.c attached.

> I'm a bit worried that we've now got a strange mix of code that "knows" which 
> areas are available and code that does probing. I'm also a bit worried about 
> the overhead of doing that probing.

It takes ~3.3 seconds on my system to probe whole address space. I don't
think that it's a lot.

> > > One question I have though... What happens, if a start up script (ini
> > > script) run in qemu linux-user changes /proc/sys/vm/mmap_min_addr from 0
> > > to say 65536? Can this ever work, without later memory allocs with
> > > mmap() failing?
> >
> > If I understood you correctly, it's one more reason for new
> > mmap_find_vma(). I guess, it should work fine, but I haven't tested this
> > case.
> 
> That's generally a different problem. Linux applications tend to be mapped at 
> a fixed address (typically 0x8000 for ARM) If your host system has randomly 
> decided to disallow this then you've much bigger problems..

Understood. On other hand the old code knows nothing about mmap_min_addr
since it only uses page table and we will got EPERM on mmap().
-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.org/

test.c
Description: Text document

signature.asc
Description: Digital signature