From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751178Ab3ACFK5 (ORCPT ); Thu, 3 Jan 2013 00:10:57 -0500 Received: from mail-pb0-f52.google.com ([209.85.160.52]:40000 "EHLO mail-pb0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750723Ab3ACFKz (ORCPT ); Thu, 3 Jan 2013 00:10:55 -0500 Date: Wed, 2 Jan 2013 21:10:48 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Simon Jeons cc: Petr Holasek , Andrea Arcangeli , Andrew Morton , Izik Eidus , Rik van Riel , David Rientjes , Sasha Levin , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Anton Arapov Subject: Re: [PATCH v7 1/2] KSM: numa awareness sysfs knob In-Reply-To: <1357030004.1379.4.camel@kernel.cn.ibm.com> Message-ID: References: <20121224050817.GA25749@kroah.com> <1356658337-12540-1-git-send-email-pholasek@redhat.com> <1357030004.1379.4.camel@kernel.cn.ibm.com> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 1 Jan 2013, Simon Jeons wrote: > > Hi Petr and Hugh, > > One offline question, thanks for your clarify. Perhaps not as offline as you intended :) > > How to understand age = (unsigned char)(ksm_scan.seqnr - > rmap_item->address);? It used for what? As you can see, remove_rmap_item_from_tree uses it to decide whether or not it should rb_erase the rmap_item from the unstable_tree. Every full scan of all the rmap_items, we increment ksm_scan.seqnr, forget the old unstable_tree (it would just be a waste of processing to remove every node one by one), and build up the unstable_tree afresh. That works fine until we need to remove an rmap_item: then we have to be very sure to remove it from the unstable_tree if it's already been linked there during this scan, but ignore its rblinkage if that's just left over from the previous scan. A single bit would be enough to decide this; but we got it troublesomely wrong in the early days of KSM (didn't always visit every rmap_item each scan), so it's convenient to use 8 bits (the low unsigned char, stored below the FLAGs and below the page-aligned address in the rmap_item - there's lots of them, best keep them as small as we can) and do a BUG_ON(age > 1) if we made a mistake. We haven't hit that BUG_ON in over three years: if we need some more bits for something, we can cut the age down to one or two bits. Hugh