Re: CONFIG_PREEMPT and server workloads

[Andrew Morton]

Andrea Arcangeli <andrea@xxxxxxx> wrote:
>
> > They do?   kmap_atomic() disables preemption anyway.
> 
> dunno why but see:
> 
> 	spin_lock(&mm->page_table_lock);
> 	page_table = pte_offset_map(pmd, address);
> 
> 		pte_unmap(page_table);
> 		spin_unlock(&mm->page_table_lock);
> 

do_wp_page()?  The lock is there to pin the pte down isn't it?  Maybe it
can be optimised - certainly the spin_unlock() in there can be moved up a
few statements.

> Infact I wonder if we should try once more time and go atomic
> again. what you're doing right now is:
> 
> 	kmap_atomic()
> 	left = copy_user
> 	kunmap_atomic
> 	if (left) {
> 		kmap() <- persistent unscalable
> 		copy-user
> 		kunmap
> 	}
> 		
> I would suggest we should be even more aggressive like this:
> 
>         kmap_atomic()
>         left = copy_user
>         kunmap_atomic
>         if (left) {
> 		get_user()
>         	kmap_atomic()
> 	        left = copy_user
> 	        kunmap_atomic
> 		if (left) {
> 	                kmap() <- persistent unscalable
>         	        copy-user
>                 	kunmap
> 		}
>         }
> 
> 
> It's not going to trigger often anyways, but it's only a few bytecodes
> more and it sounds more scalable.

Could be.  When I did that code I had some printks in the slow path and
although it did trigger, it was rare.  We've already faulted the page in by
hand so we should only fall into the kmap() if the page was suddenly stolen
again.

But it was a long time ago - adding some instrumentation here to work out
how often we enter the slow path would tell us whether this is needed.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/