[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110630051123.GD12667@in.ibm.com>
Date: Thu, 30 Jun 2011 10:41:23 +0530
From: Ankita Garg <ankita@...ibm.com>
To: Andi Kleen <andi@...stfloor.org>
Cc: Dave Hansen <dave@...ux.vnet.ibm.com>,
linux-arm-kernel@...ts.infradead.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org,
svaidy@...ux.vnet.ibm.com, thomas.abraham@...aro.org,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
Matthew Garrett <mjg59@...f.ucam.org>,
Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH 00/10] mm: Linux VM Infrastructure to support Memory
Power Management
Hi,
On Wed, Jun 29, 2011 at 01:11:00PM -0700, Andi Kleen wrote:
> Dave Hansen <dave@...ux.vnet.ibm.com> writes:
> >
> > It's also going to be a pain to track kernel references. On x86, our
>
As Vaidy mentioned, we are only looking at memory being either allocated
or free, as a way to evacuate it. Tracking memory references, no doubt,
is a difficult proposition and might involve a lot of overhead.
> Even if you tracked them what would you do with them?
>
> It's quite hard to stop using arbitary kernel memory (see all the dancing
> memory-failure does)
>
> You need to track the direct accesses to user data which happens
> to be accessed through the direct mapping.
>
> Also it will be always unreliable because this all won't track DMA.
> For that you would also need to track in the dma_* infrastructure,
> which will likely get seriously expensive.
>
--
Regards,
Ankita Garg (ankita@...ibm.com)
Linux Technology Center
IBM India Systems & Technology Labs,
Bangalore, India
--
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