[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1357259044.4930.4.camel@kernel.cn.ibm.com>
Date: Thu, 03 Jan 2013 18:24:04 -0600
From: Simon Jeons <simon.jeons@...il.com>
To: Hugh Dickins <hughd@...gle.com>
Cc: Petr Holasek <pholasek@...hat.com>,
Andrea Arcangeli <aarcange@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Izik Eidus <izik.eidus@...ellosystems.com>,
Rik van Riel <riel@...hat.com>,
David Rientjes <rientjes@...gle.com>,
Sasha Levin <sasha.levin@...cle.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Anton Arapov <anton@...hat.com>
Subject: Re: [PATCH v7 1/2] KSM: numa awareness sysfs knob
On Wed, 2013-01-02 at 21:10 -0800, Hugh Dickins wrote:
> 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 :)
Hi Hugh,
Thanks for your detail explanation. :)
>
> >
> > 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.
>
When the rmap_items left over from the previous scan will be removed?
> 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
When the scenario didn't always visit every rmap_item each scan can
occur?
> 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
--
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