Re: freemaps

[Andrew Morton <akpm@digeo.com>]

"Frederic Rossi (LMC)" wrote:
> 
> ...
> 100000 mmaps, mmap=2545 msec munmap=59 msec
> 100000 mmaps, mmap=2545 msec munmap=58 msec
> 100000 mmaps, mmap=2544 msec munmap=60 msec
> 100000 mmaps, mmap=2547 msec munmap=60 msec
> 
> and with freemaps I get
> 100000 mmaps, mmap=79 msec munmap=60 msec
> 100000 mmaps, mmap=79 msec munmap=60 msec
> 100000 mmaps, mmap=80 msec munmap=60 msec
> 100000 mmaps, mmap=79 msec munmap=60 msec
> 

Yes, this is a real failing.

>  
> +ssize_t proc_pid_read_vmc (struct task_struct *task, struct file * file, char * buf, size_t count, loff_t *ppos)
> +{

This should use the seq_file API.

> +struct vma_cache_struct {
> +	struct list_head head;
> +	unsigned long vm_start;
> +	unsigned long vm_end;
> +};

So this is the key part.  It is a per-mm linear list of unmapped areas.

You state that its locking is via mm->mmap_sem.  I assume that means
a down_write() of that semaphore?

As this is a linear list, I do not understand why it does not have similar failure
modes to the current search.  Suppose this list describes 100,000 4k unmapped
areas and the application requests an 8k mmap??

> +static __inline__ int vma_cache_chainout (struct mm_struct *mm, struct vma_cache_struct *vmc)
> +{
> +	if (!vmc)
> +		return -EINVAL;
> +
> +	list_del_init (&vmc->head);
> +	vma_cache_free (vmc);

vma_cache_free() already does the list_del_init().
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/