[lkml]   [2011]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] mm: Delete non-atomic mm counter implementation
On Wed, 27 Apr 2011 15:36:05 +0100
Matt Fleming <> wrote:

> From: Matt Fleming <>
> The problem with having two different types of counters is that
> developers adding new code need to keep in mind whether it's safe to
> use both the atomic and non-atomic implementations. For example, when
> adding new callers of the *_mm_counter() functions a developer needs
> to ensure that those paths are always executed with page_table_lock
> held, in case we're using the non-atomic implementation of mm
> counters.
> Hugh Dickins introduced the atomic mm counters in commit f412ac08c986
> ("[PATCH] mm: fix rss and mmlist locking"). When asked why he left the
> non-atomic counters around he said,
> | The only reason was to avoid adding costly atomic operations into a
> | configuration that had no need for them there: the page_table_lock
> | sufficed.
> |
> | Certainly it would be simpler just to delete the non-atomic variant.
> |
> | And I think it's fair to say that any configuration on which we're
> | measuring performance to that degree (rather than "does it boot fast?"
> | type measurements), would already be going the split ptlocks route.
> Removing the non-atomic counters eases the maintenance burden because
> developers no longer have to mindful of the two implementations when
> using *_mm_counter().
> Note that all architectures provide a means of atomically updating
> atomic_long_t variables, even if they have to revert to the generic
> spinlock implementation because they don't support 64-bit atomic
> instructions (see lib/atomic64.c).
> Signed-off-by: Matt Fleming <>

now mm_counters are update in per-thread and removing non-atomic
will not have big impact in performance, I hope.

Acked-by: KAMEZAWA Hiroyuki <>

 \ /
  Last update: 2011-04-28 02:17    [W:0.056 / U:3.456 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site