public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <jbeulich@novell.com>
To: "Jeremy Fitzhardinge" <jeremy@goop.org>,
	"Zachary Amsden" <zach@vmware.com>
Cc: <linux-kernel@vger.kernel.org>
Subject: arch_flush_lazy_mmu_mode() in arch/x86/mm/highmem_32.c
Date: Mon, 17 Nov 2008 09:08:10 +0000	[thread overview]
Message-ID: <4921428A.76E4.0078.0@novell.com> (raw)

Commit 49f19710512c825aaea73b9207b3a848027cda1d hints at the
current solution not being the final one, yet the advertised (for 2.6.22)
change apparently never happened. However, it seems to me that
flushing a potentially huge (it terms of time to completion) batch
asynchronously is no really good idea. Instead, I'd think that adding to
the batch should be prevented in asynchronous contexts altogether, or
things should properly nest. As a positive side effect, disabling interrupts
in the batch handling - in particular around the submission of the batch -
could also be avoided, reducing interrupt latency (perhaps significantly
in some case).

Likewise I would think that the flush out of vmalloc_sync_one() isn't
appropriate, and it should rather be avoided for the set_pmd() there to
get into the batching code altogether.

(Background to this: After adding lazy mmu mode support in our forward
ported tree, we've actually been hit by these calls out of kmap_...(), as
originally I didn't pay much attention to these and didn't care to synchronize
batch addition and flushing with asynchronous operations.)

Jan


             reply	other threads:[~2008-11-17  9:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-17  9:08 Jan Beulich [this message]
2008-11-17 17:53 ` arch_flush_lazy_mmu_mode() in arch/x86/mm/highmem_32.c Zachary Amsden
2008-11-17 18:40   ` Jeremy Fitzhardinge
2008-11-17 19:54     ` Zachary Amsden
2008-11-18  8:03     ` Jan Beulich
2008-11-18 17:01       ` Jeremy Fitzhardinge
2008-11-18 17:28         ` Jan Beulich
2008-11-18 18:00           ` Jeremy Fitzhardinge
2008-11-18 18:06           ` Zachary Amsden

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=4921428A.76E4.0078.0@novell.com \
    --to=jbeulich@novell.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zach@vmware.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