[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140903095815.GK4783@worktop.ger.corp.intel.com>
Date: Wed, 3 Sep 2014 11:58:15 +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>
Subject: Re: [PATCH v4 2/2] ksm: provide support to use deferrable timers for
scanner thread
On Wed, Aug 27, 2014 at 11:02:20PM -0700, Hugh Dickins wrote:
> Sorry for holding you up, I'm slow. and needed to think about this more,
>
> On Wed, 20 Aug 2014, Chintan Pandya wrote:
>
> > KSM thread to scan pages is scheduled on definite timeout. That wakes up
> > CPU from idle state and hence may affect the power consumption. Provide
> > an optional support to use deferrable timer which suites low-power
> > use-cases.
> >
> > Typically, on our setup we observed, 10% less power consumption with some
> > use-cases in which CPU goes to power collapse frequently. For example,
> > playing audio on Soc which has HW based Audio encoder/decoder, CPU
> > remains idle for longer duration of time. This idle state will save
> > significant CPU power consumption if KSM don't wakes them up
> > periodically.
> >
> > Note that, deferrable timers won't be deferred if any CPU is active and
> > not in IDLE state.
> >
> > By default, deferrable timers is enabled. To disable deferrable timers,
> > $ echo 0 > /sys/kernel/mm/ksm/deferrable_timer
>
> I have now experimented. And, much as I wanted to eliminate the
> tunable, and just have deferrable timers on, I have come right back
> to your original position.
>
> I was impressed by how quiet ksmd goes when there's nothing much
> happening on the machine; but equally, disappointed in how slow
> it then is to fulfil the outstanding merge work. I agree with your
> original assessment, that not everybody will want deferrable timer,
> the way it is working at present.
>
> I expect that can be fixed, partly by doing more work on wakeup from
> a deferred timer, according to how long it has been deferred; and
> partly by not deferring on idle until two passes of the list have been
> completed. But that's easier said than done, and might turn out to
So why not have the timer cancel itself when there is no more work to do
and start itself up again when there's work added?
--
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