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, 13 Oct 2011 18:25:06 -0700 From: Michel Lespinasse <walken@...gle.com> To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com> Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>, Dave Hansen <dave@...ux.vnet.ibm.com>, Rik van Riel <riel@...hat.com>, Balbir Singh <bsingharora@...il.com>, Peter Zijlstra <a.p.zijlstra@...llo.nl>, Andrea Arcangeli <aarcange@...hat.com>, Johannes Weiner <jweiner@...hat.com>, KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>, Hugh Dickins <hughd@...gle.com>, Michael Wolf <mjwolf@...ibm.com> Subject: Re: [PATCH 6/9] kstaled: rate limit pages scanned per second. On Wed, Sep 28, 2011 at 1:59 AM, KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com> wrote: > On Wed, 28 Sep 2011 01:19:50 -0700 > Michel Lespinasse <walken@...gle.com> wrote: >> It tends to perform worse if we try making it multithreaded. What >> happens is that the scanning threads call page_referenced() a lot, and >> if they both try scanning pages that belong to the same file that >> causes the mapping's i_mmap_mutex lock to bounce. Same things happens >> if they try scanning pages that belong to the same anon VMA too. >> > > Hmm. with brief thinking, if you can scan list of page tables, > you can set young flags without any locks. > For inode pages, you can hook page lookup, I think. It would be possible to avoid taking rmap locks by instead scanning all page tables, and transferring the pte young bits observed there to the PageYoung page flag. This is a significant design change, but would indeed work. Just to clarify the idea, how would you go about finding all page tables to scan ? The most straightforward approach would be iterate over all processes and scan their address spaces, but I don't think we can afford to hold tasklist_lock (even for reads) for so long, so we'd have to be a bit smarter than that... I can think of a few different ways but I'd like to know if you have something specific in mind first. -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- 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