[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070302190245.GA10019@linux.intel.com>
Date: Fri, 2 Mar 2007 11:02:45 -0800
From: Mark Gross <mgross@...ux.intel.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Balbir Singh <balbir@...ibm.com>, Mel Gorman <mel@...net.ie>,
npiggin@...e.de, clameter@...r.sgi.com, mingo@...e.hu,
jschopp@...tin.ibm.com, arjan@...radead.org, mbligh@...igh.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: The performance and behaviour of the anti-fragmentation related patches
On Fri, Mar 02, 2007 at 10:02:57AM -0800, Andrew Morton wrote:
> On Fri, 2 Mar 2007 09:35:27 -0800
> Mark Gross <mgross@...ux.intel.com> wrote:
>
> > >
> > > Will it be possible to just power the DIMMs off? I don't see much point in
> > > some half-power non-destructive mode.
> >
> > I think so, but need to double check with the HW folks.
> >
> > Technically, the dims could be powered off, and put into 2 different low
> > power non-destructive states. (standby and suspend), but putting them
> > in a low power non-destructive mode has much less latency and provides
> > good bang for the buck or LOC change needed to make work.
> >
> > Which lower power mode an application chooses will depend on latency
> > tolerances of the app. For the POC activities we are looking at we are
> > targeting the lower latency option, but that doesn't lock out folks from
> > trying to do something with the other options.
> >
>
> If we don't evacuate all live data from all of the DIMM, we'll never be
> able to power the thing down in many situations.
>
> Given that we _have_ emptied the DIMM, we can just turn it off. And
> refilling it will be slow - often just disk speed.
>
> So I don't see a useful use-case for non-destructive states.
I'll post the RFC very soon to provide a better thread context for this
line of discussion, but to answer your question:
There are 2 power management policies we are looking at. The first one
is allocation based PM, and the other is access base PM. The access
based PM needs chip set support which is coming at a TBD date.
--mgross
-
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