On Fri, 5 Aug 2005, Andi Kleen wrote:
> > Address space migration? That is something new in this discussion. So
> > could you explain what you mean by that? I have looked at page migration
> > in a variety of contexts and could not see much difference.
>
> MCE page migration just puts a physica
On Fri, 5 Aug 2005, Andi Kleen wrote:
> > a clean way. It cannot even deliver the functionality it was designed to
> > deliver (see BIND).
>
> That seems like a unfair description to me. While things are not
> perfect they are definitely not as bad as you're trying to paint them.
Sorry this wen
On Thu, Aug 04, 2005 at 04:49:33PM -0700, Christoph Lameter wrote:
> On Fri, 5 Aug 2005, Andi Kleen wrote:
>
> > None of them seem very attractive to me. I would prefer to just
> > not support external accesses keeping things lean and fast.
>
> That is a surprising statement given what we just d
On Fri, 5 Aug 2005, Andi Kleen wrote:
> None of them seem very attractive to me. I would prefer to just
> not support external accesses keeping things lean and fast.
That is a surprising statement given what we just discussed. Things
are not lean and fast but weirdly screwed up. The policy laye
On Thu, Aug 04, 2005 at 03:19:52PM -0700, Christoph Lameter wrote:
> There are three possibilites:
>
> 1. do what cpusets is doing by versioning.
>
> 2. Have the task notifier access the task_struct information.
> See http://lwn.net/Articles/145232/ "A new path to the refrigerator"
>
> 3. Maybe
On Thu, Aug 04, 2005 at 03:19:52PM -0700, Christoph Lameter wrote:
> This code already exist in the memory hotplug code base and Ray already
> had a working implementation for page migration. The migration code will
> also be necessary in order to relocate pages with ECC single bit failures
> th
On Thu, 4 Aug 2005, Andi Kleen wrote:
> > There is this scan over the page table that verifies if all nodes are
> > allocated according to the policy. That scan could easily be used to
> > provide a map to the application (and to /proc//smap) of where the
>
> The application can already get it.
On Thu, Aug 04, 2005 at 02:21:09PM -0700, Christoph Lameter wrote:
> Yes he mentioned that patch earlier in this thread.
>
> > > 5. No means to figure out where the memory was allocated although
> > >mempoliy.c implements scans over ptes that would allow that
> > >determination.
> >
> >
On Thu, 4 Aug 2005, Andi Kleen wrote:
> > 1. BIND policy implemented in a way that fills up nodes from the lowest
> >to the higest instead of allocating memory on the local node.
>
> Hmm, there was a patch from PJ for that at some point. Not sure why it
> was not merged. iirc the first impl
> 1. BIND policy implemented in a way that fills up nodes from the lowest
>to the higest instead of allocating memory on the local node.
Hmm, there was a patch from PJ for that at some point. Not sure why it
was not merged. iirc the first implementation was too complex, but
there was a secon
10 matches
Mail list logo
