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: Fri, 04 Jan 2013 18:30:07 -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 Fri, 2013-01-04 at 15:03 -0800, Hugh Dickins wrote: > On Thu, 3 Jan 2013, Simon Jeons wrote: > > On Wed, 2013-01-02 at 21:10 -0800, Hugh Dickins wrote: > > > > > > 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? > > Removed from the unstable rbtree? Not at all, it's simply restarted > afresh, and the old rblinkages ignored. Freed back to slab? When the > scan passes that mm+address and realizes that rmap_item is not wanted > any more. (Or when ksm is shut down with KSM_RUN_UNMERGE.) > Make sense. Thanks Hugh. :) > > > > > 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? > > You're asking me about a stage of KSM development 3.5 years ago: > I don't remember the details. > > > > > > 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