* Andrew Morton <[email protected]> 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:
http://www.fedoraproject.org/awstats/stats/updates-released-fc6-i386.total
http://www.fedoraproject.org/awstats/stats/updates-released-fc6-x86_64.total
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()
users.
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.)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
