From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org-S268070AbUJCSnB@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S268070AbUJCSnB (ORCPT <rfc822;willy@w.ods.org>);
	Sun, 3 Oct 2004 14:43:01 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S268072AbUJCSks
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Sun, 3 Oct 2004 14:40:48 -0400
Received: from scanner1.mail.elte.hu ([157.181.1.137]:51627 "EHLO mx1.elte.hu")
	by vger.kernel.org with ESMTP id S268059AbUJCSeg (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 3 Oct 2004 14:34:36 -0400
Date: Sun, 3 Oct 2004 20:36:12 +0200
From: Ingo Molnar <mingo@elte.hu>
To: Hugh Dickins <hugh@veritas.com>
Cc: Andrew Morton <akpm@osdl.org>, Andrea Arcangeli <andrea@suse.de>,
       Rajesh Venkatasubramanian <vrajesh@umich.edu>,
       Lorenzo Allegrucci <l_allegrucci@yahoo.it>,
       linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/6] vmtrunc: restore unmap_vmas zap_bytes
Message-ID: <20041003183612.GA29653@elte.hu>
References: <Pine.LNX.4.44.0410031914480.2739-100000@localhost.localdomain> <Pine.LNX.4.44.0410031923390.2755-100000@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44.0410031923390.2755-100000@localhost.localdomain>
User-Agent: Mutt/1.4.1i
X-ELTE-SpamVersion: MailScanner 4.31.6-itk1 (ELTE 1.2) SpamAssassin 2.63 ClamAV 0.73
X-ELTE-VirusStatus: clean
X-ELTE-SpamCheck: no
X-ELTE-SpamCheck-Details: score=-4.9, required 5.9,
	autolearn=not spam, BAYES_00 -4.90
X-ELTE-SpamLevel: 
X-ELTE-SpamScore: -4
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org


* Hugh Dickins <hugh@veritas.com> wrote:

> The low-latency unmap_vmas patch silently moved the zap_bytes test
> after the TLB finish and lockbreak and regather: why?  That not only
> makes zap_bytes redundant (might as well use ZAP_BLOCK_SIZE), it makes
> the unmap_vmas level redundant too - it's all about saving TLB flushes
> when unmapping a series of small vmas.

the problem was latency generated by pages queueing up in tlb_gather's 
queue and being freed in one loop, causing latencies. So there was no 
latency-break, only a shifting of the queue.

> Move zap_bytes test back before the lockbreak, and delete the curious
> comment that a small zap block size doesn't matter: it's true
> need_flush prevents TLB flush when no page has been unmapped, but
> unmapping pages in small blocks involves many more TLB flushes than in
> large blocks.

could we perhaps free those pages outside of the lock? That would be
just as good for me.

	Ingo