linux-kernel - Re: [PATCH v4 2/2] ksm: provide support to use deferrable timers for scanner thread

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140910082726.GO6758@twins.programming.kicks-ass.net>
Date:	Wed, 10 Sep 2014 10:27:26 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Hugh Dickins <hughd@...gle.com>
Cc:	Chintan Pandya <cpandya@...eaurora.org>, akpm@...ux-foundation.org,
	linux-mm@...ck.org, linux-arm-msm@...r.kernel.org,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	John Stultz <john.stultz@...aro.org>,
	Ingo Molnar <mingo@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Paul McKenney <paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCH v4 2/2] ksm: provide support to use deferrable timers for
 scanner thread

On Tue, Sep 09, 2014 at 01:14:50PM -0700, Hugh Dickins wrote:
> > Quite horrible for sure. I really hate seeing KSM cruft all the way down
> 
> Yes, I expected that, and I would certainly feel the same way.
> 
> And even worse, imagine if this were successful, we might come along
> and ask to do something similar for khugepaged.  Though if it comes to
> that, I'm sure we would generalize into one hook which does not say
> "ksm" or "khugepaged" on it, but would still a present a single unlikely
> flag to be tested at this level.  Maybe you would even prefer the
> generalized version, but I don't want to complicate the prototype yet.
> 
> If it weren't for the "we already have the mm cachelines here" argument,
> I by now feel fairly sure that I would be going for hooking into timer
> tick instead (where Thomas could then express his horror!).
> 
> Do you think I should just forget about cacheline micro-optimizations
> and go in that direction instead?

Not really either I'm afraid. Slimming down the tick has been on my todo
list like forever. There's a lot of low hanging fruit there.

> > here. Can't we create a new (timer) infrastructure that does the right
> > thing? Surely this isn't the only such case.
> 
> A sleep-walking timer, that goes to sleep in one bed, but may wake in
> another; and defers while beds are empty?  I'd be happy to try using
> that for KSM if it already existed, and no doubt Chintan would too
> 
> But I don't think KSM presents a very good case for developing it.
> I think KSM's use of a sleep_millisecs timer is really just an apology
> for the amount of often wasted work that it does, and dates from before
> we niced it down 5.  I prefer the idea of a KSM which waits on activity
> amongst the restricted set of tasks it is tracking: as this patch tries.
> 
> But my preference may be naive: doing lots of unnecessary work doesn't
> matter as much as waking cpus from deep sleep.

Ah yes, I see your point. So far the mentioned goal has been to not
unduly wake CPUs and waste energy, but your goal is better still. And
would indeed not be met by a globally deferred timer.

Does it make sense to drive both KSM and khugepage the same way we drive
the numa scanning? It has the benefit of getting rid of these threads,
which pushes the work into the right accountable context (the task its
doing the scanning for) and makes the scanning frequency depend on the
actual task activity.



Content of type "application/pgp-signature" skipped