LKML Archive on
help / color / mirror / Atom feed
From: Ingo Molnar <>
To: Andrew Morton <>
Cc: Peter Zijlstra <>,,
Subject: Re: [PATCH] mm: remove global locks from mm/highmem.c
Date: Mon, 29 Jan 2007 20:08:06 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

* Andrew Morton <> wrote:

> > Eradicate global locks.
> > 
> >  - kmap_lock is removed by extensive use of atomic_t, a new flush
> >    scheme and modifying set_page_address to only allow NULL<->virt
> >    transitions.

> I really don't recall any performance problems being reported out of 
> that code in recent years.

well, almost nobody profiles 32-bit boxes. I personally always knew that 
kmap() sucks on certain 32-bit SMP workloads (and -rt's scheduling model 
makes such bottlenecks even more apparent) - but many people acted in 
the belief that 64-bit is all that matters and 32-bit scalability is 
obsolete. Here are the numbers that i think changes the picture:

For every 64-bit Fedora box there's more than seven 32-bit boxes. I 
think 32-bit is going to live with us far longer than many thought, so 
we might as well make it work better. Both HIGHMEM and HIGHPTE is the 
default on many distro kernels, which pushes the kmap infrastructure 
quite a bit.

> As Christoph says, it's very much preferred that code be migrated over 
> to kmap_atomic().  Partly because kmap() is deadlockable in situations 
> where a large number of threads are trying to take two kmaps at the 
> same time and we run out.  This happened in the past, but incidences 
> have gone away, probably because of kmap->kmap_atomic conversions.

the problem is that everything that was easy to migrate was migrated off 
kmap() already - and it's exactly those hard cases that cannot be 
converted (like the pagecache use) which is the most frequent kmap() 

While "it would be nice" to eliminate kmap(), but reality is that it's 
here and the patches from Peter to make it (quite a bit) more scalable 
are here as well.

plus, with these fixes kmap() is actually faster than kmap_atomic(). 
(because kunmap_atomic() necessiates an INVLPG instruction which is 
quite slow.)


  parent reply	other threads:[~2007-01-29 19:09 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-28 14:11 Peter Zijlstra
2007-01-28 14:49 ` Christoph Hellwig
2007-01-28 15:17   ` Ingo Molnar
2007-01-28 15:28     ` Christoph Hellwig
2007-01-28 15:48       ` Ingo Molnar
2007-01-28 15:54         ` Christoph Hellwig
2007-01-28 18:19           ` Ingo Molnar
2007-01-28 22:29 ` Andrew Morton
2007-01-29  2:52   ` Nick Piggin
2007-01-29  9:44   ` Peter Zijlstra
2007-01-30  1:31     ` Martin J. Bligh
2007-01-30  1:41       ` Andrew Morton
2007-01-30  1:49         ` Martin J. Bligh
2007-01-30  2:15           ` Andrew Morton
2007-01-31  0:44             ` David Chinner
2007-01-31  1:11               ` Andrew Morton
2007-01-31  3:22                 ` David Chinner
2007-02-02 12:05                   ` Christoph Hellwig
2007-02-02 19:24                     ` Matt Mackall
2007-02-02 23:16                       ` David Chinner
2007-02-02 23:14                     ` David Chinner
2007-01-29 19:08   ` Ingo Molnar [this message]
2007-01-29 19:19     ` Hugh Dickins
2007-01-29 19:53       ` Ingo Molnar
2007-01-29 20:06     ` Ingo Molnar
2007-01-30  2:02     ` Nick Piggin

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: [PATCH] mm: remove global locks from mm/highmem.c' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).