From: Andrea Arcangeli <andrea@suse.de>
To: Mark Hemment <markhe@veritas.com>
Cc: Linus Torvalds <torvalds@transmeta.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Align VM locks
Date: Thu, 16 Aug 2001 20:52:24 +0200 [thread overview]
Message-ID: <20010816205224.C8726@athlon.random> (raw)
In-Reply-To: <20010816202606.B8726@athlon.random> <Pine.LNX.4.33.0108161933240.3340-100000@alloc.wat.veritas.com>
In-Reply-To: <Pine.LNX.4.33.0108161933240.3340-100000@alloc.wat.veritas.com>; from markhe@veritas.com on Thu, Aug 16, 2001 at 07:44:04PM +0100
On Thu, Aug 16, 2001 at 07:44:04PM +0100, Mark Hemment wrote:
> At least on the work load I'm interest in, SpecFS v2.0 over NFSv3,
> removing the KM_BOUNCE_WRITE results in a performance drop (confirmed
> today).
>
> It is often the case that when it comes time to write a page out it has
> lost any mapping it had when it was made dirty via a write(), so there is
> no side benefit of using a straight kmap().
>
> By having KM_BOUNCE_WRITE we don't run through the "normal" mapping
> space on I/O. Not having KM_BOUNCE_WRITE causing extra shootdowns, which
> _are_ expensive, as the code needs to busy-wait for all the other engines
> (while the kmap_lock held - and on a 4-way there is a good chance one of
> the processors is running with interrupts disabled).
> KM_BOUNCE_WRITE may waste virtual address-space, but it saves on
> expensive shootdowns.
I would never save addresss-space for performance of course, it's just
that it is unused in my tree so it doesn't make sense to left it.
I believe the slowdown is more a sign that kmap is not fast enoguh, not
that you really need the BOUNCE_WRITE. I'd suggest to try to invlpg at
kmap time entry-per-entry and to skip the global tlb flush during the
wrap around as first thing and mark the kmap entries global (since it is
safe with the invlpg) and see if it changes something. If kmap hurts on
the I/O path it means it hurts on the pagecache read/writes etc... too,
so lefting KM_BOUNCE_WRITE looks more hiding the performance hit instead
of fixing it.
Andrea
next prev parent reply other threads:[~2001-08-16 18:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-16 17:41 [PATCH] Align VM locks Mark Hemment
2001-08-16 18:26 ` Andrea Arcangeli
2001-08-16 18:44 ` Mark Hemment
2001-08-16 18:52 ` Andrea Arcangeli [this message]
2001-08-16 18:57 ` Andrea Arcangeli
2001-08-16 19:46 ` Mark Hemment
2001-08-16 20:27 ` Ben LaHaise
2001-08-16 23:35 ` Andrea Arcangeli
2001-08-16 19:14 ` Andrew Morton
2001-08-16 23:33 ` Andrea Arcangeli
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=20010816205224.C8726@athlon.random \
--to=andrea@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=markhe@veritas.com \
--cc=torvalds@transmeta.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox