Re: 2.6.16-rc1: 28ms latency when process with lots of swapped memoryexits

[Nick Piggin]

Hugh Dickins wrote:

> Oh, thank you for forcing me to take another look, 2.6.15 did make a
> regression there, and this one is very simply remedied: Lee, please
> try the patch below (I've done it against 2.6.16-rc6 because that's
> what I have to hand; and would be a better tree for you to test),
> and let us know if it fixes your case as I expect - thanks.
>
> (Robin Holt observed how inefficient the small ZAP_BLOCK_SIZE was on
> very sparse mmaps, as originally implemented; so he and Nick reworked
> it to count only real work done; but the swap entries got put on the
> side of "no real work", whereas you've found they may involve very
> significant work.  My patch below reverses that: yes, I've got some
> other cases now going the slow way when they needn't, but they're
> too rare to clutter the code for.)

I think this patch looks good, thanks Hugh.

> Hugh
>
> --- 2.6.16-rc6/mm/memory.c	2006-03-12 15:25:45.000000000 +0000
> +++ linux/mm/memory.c	2006-03-15 07:32:36.000000000 +0000
> @@ -623,11 +623,12 @@ static unsigned long zap_pte_range(struc
>  			(*zap_work)--;
>  			continue;
>  		}
> +
> +		(*zap_work) -= PAGE_SIZE;
> +
>  		if (pte_present(ptent)) {
>  			struct page *page;
>  
> -			(*zap_work) -= PAGE_SIZE;
> -
>  			page = vm_normal_page(vma, addr, ptent);
>  			if (unlikely(details) && page) {
>  				/*


--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 
-
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/