lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 28 Apr 2011 09:08:57 +0900 From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com> To: Matt Fleming <matt@...sole-pimps.org> Cc: Dave Hansen <dave@...ux.vnet.ibm.com>, Hugh Dickins <hughd@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...r.kernel.org, linux-kernel@...r.kernel.org, Matt Fleming <matt.fleming@...ux.intel.com> Subject: Re: [PATCH] mm: Delete non-atomic mm counter implementation On Wed, 27 Apr 2011 15:36:05 +0100 Matt Fleming <matt@...sole-pimps.org> wrote: > From: Matt Fleming <matt.fleming@...ux.intel.com> > > 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 <matt.fleming@...ux.intel.com> 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 <kamezawa.hiroyu@...fujitsu.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists