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
Date: Sun, 3 Oct 2004 20:36:12 +0200 [thread overview]
Message-ID: <20041003183612.GA29653@elte.hu> (raw)
In-Reply-To: <Pine.LNX.4.44.0410031923390.2755-100000@localhost.localdomain>
* 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
next prev parent reply other threads:[~2004-10-03 18:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-03 18:21 [PATCH 0/6] vmtrunc: lowlat vmtruncate drop i_mmap_lock Hugh Dickins
2004-10-03 18:23 ` [PATCH 1/6] vmtrunc: truncate_count not atomic Hugh Dickins
2004-10-03 18:24 ` [PATCH 2/6] vmtrunc: restore unmap_vmas zap_bytes Hugh Dickins
2004-10-03 18:36 ` Ingo Molnar [this message]
2004-10-03 18:25 ` [PATCH 3/6] vmtrunc: unmap_mapping_range_tree Hugh Dickins
2004-10-03 18:26 ` [PATCH 4/6] vmtrunc: unmap_mapping dropping i_mmap_lock Hugh Dickins
2004-10-03 18:27 ` [PATCH 5/6] vmtrunc: vm_truncate_count race caution Hugh Dickins
2004-10-03 18:28 ` [PATCH 6/6] vmtrunc: bug if page_mapped Hugh Dickins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041003183612.GA29653@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@osdl.org \
--cc=andrea@suse.de \
--cc=hugh@veritas.com \
--cc=l_allegrucci@yahoo.it \
--cc=linux-kernel@vger.kernel.org \
--cc=vrajesh@umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.