On Thu, 11 Sep 2014, Chintan Pandya wrote:
> I don't mean to divert the thread too much. But just one suggestion offered
> by Harshad.
>
> Why can't we stop invoking more of a KSM scanner thread when we are
> saturating from savings ? But again, to check whether savings are saturated
> or not, we
On Wed, 10 Sep 2014, Peter Zijlstra wrote:
>
> 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 ma
On Wed, 10 Sep 2014, Peter Zijlstra wrote:
>
> So if this were switch_to(), we'd see next->mm as before the last
> context switch. And since that switch fully happened, it would also
> already have done the finish_task_switch() -> mmdrop().
Useful words of warning, thank you, which jolted me into
I don't mean to divert the thread too much. But just one suggestion
offered by Harshad.
Why can't we stop invoking more of a KSM scanner thread when we are
saturating from savings ? But again, to check whether savings are
saturated or not, we may still want to rely upon timers and we have to
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 so
On Tue, Sep 09, 2014 at 01:14:50PM -0700, Hugh Dickins wrote:
> On Mon, 8 Sep 2014, Peter Zijlstra wrote:
> > > switch_mm(oldmm, mm, next);
> > > + wake_ksm = ksm_switch(mm);
> >
> > Is this the right mm?
>
> It's next->mm, that's the one I intended (though the patch might
> be
On Tue, 9 Sep 2014, Chintan Pandya wrote:
> Hello All,
>
> Before its too late to discuss this basic question, allow me to share my view
> on the deferrable timer approach.
>
> I believe KSM at this point is tunable with predictable outcomes. When it
> will get triggered, how many pages it will s
On Mon, 8 Sep 2014, Peter Zijlstra wrote:
> On Mon, Sep 08, 2014 at 01:25:36AM -0700, Hugh Dickins wrote:
> >
> > --- 3.17-rc4/include/linux/ksm.h2014-03-30 20:40:15.0 -0700
> > +++ linux/include/linux/ksm.h 2014-09-07 11:54:41.528003316 -0700
>
> > @@ -87,6 +96,11 @@ static inl
Hello All,
Before its too late to discuss this basic question, allow me to share my
view on the deferrable timer approach.
I believe KSM at this point is tunable with predictable outcomes. When
it will get triggered, how many pages it will scan etc. This aggression
control is with user who c
On Mon, Sep 08, 2014 at 01:25:36AM -0700, Hugh Dickins wrote:
> Well, yes, but... how do we know when there is no more work to do?
Yeah, I figured that out _after_ I send that email..
> Thomas has given reason why KSM might simply fail to do its job if we
> rely on the deferrable timer. So I've
On Wed, 3 Sep 2014, Peter Zijlstra wrote:
> On Wed, Aug 27, 2014 at 11:02:20PM -0700, Hugh Dickins wrote:
> > 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 consu
On Wed, 3 Sep 2014, Peter Zijlstra wrote:
> 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 tim
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
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 def
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
u
15 matches
Mail list logo
