lkml.org 
[lkml]   [2009]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH 0/4] memcg: add support for hwpoison testing
On Tue, Sep 01, 2009 at 07:46:26AM +0800, KAMEZAWA Hiroyuki wrote:
> On Mon, 31 Aug 2009 18:26:40 +0800
> Wu Fengguang <fengguang.wu@intel.com> wrote:
>
> > Hi all,
> >
> > In hardware poison testing, we want to inject hwpoison errors to pages
> > of a collection of selected tasks, so that random tasks (eg. init) won't
> > be killed in stress tests and lead to test failure.
> >
> > Memory cgroup provides an ideal tool for tracking and testing these target
> > process pages. All we have to do is to
> > - export the memory cgroup id via cgroupfs
> > - export two functions/structs for hwpoison_inject.c
> >
> > This might be an unexpected usage of memory cgroup. The last patch and this
> > script demonstrates how the exported interfaces are to be used to limit the
> > scope of hwpoison injection.
> >
> > test -d /cgroup/hwpoison && rmdir /cgroup/hwpoison
> > mkdir /cgroup/hwpoison
> >
> > usemem -m 100 -s 100 & # eat 100MB and sleep 100s
> > echo `pidof usemem` > /cgroup/hwpoison/tasks
> >
> > ==> memcg_id=$(</cgroup/hwpoison/memory.id)
> > ==> echo $memcg_id > /debug/hwpoison/corrupt-filter-memcg
> >
> > # hwpoison all pfn
> > pfn=0
> > while true
> > do
> > let pfn=pfn+1
> > echo $pfn > /debug/hwpoison/corrupt-pfn
> > if [ $? -ne 0 ]; then
> > break
> > fi
> > done
> >
>
> I don't like this.
>
> 1. plz put all under CONFIG_DEBUG_HWPOISON or some
> 2. plz don't export memcg's id. you can do it without it.

No problem.

My intention was, as memcg users grow in future, the export of
memcg functions and maybe its id will be generally useful then.

Matching by memcg dir name is acceptable for our case, however
won't be suitable for general use: there are file name uniqueness,
string escaping and efficiency issues.

> 3. If I was you, just adds following file
>
> memory.hwpoison_test
> Then, if you allow test
> #echo 1 > memory.hwpoison_test

No that would look ugly in the long term. I'd rather go for dir name
matching for now.

> 4. I can't understand why you need this. I wonder you can get pfn via
> /proc/<pid>/????. And this may insert HWPOISON to page-cache of shared
> library and "unexpected" process will be poisoned.

Sorry I should have explained this. It's mainly for correctness.
When a user space tool queries the task PFNs in /proc/pid/pagemap and
then send to /debug/hwpoison/corrupt-pfn, there is a racy window that
the page could be reclaimed and allocated by some one else. It would
be awkward to try to pin the pages in user space. So we need the
guarantees provided by /debug/hwpoison/corrupt-filter-memcg, which
will be checked inside the page lock with elevated reference count.

Thanks,
Fengguang


\
 
 \ /
  Last update: 2009-09-01 04:37    [from the cache]
©2003-2011 Jasper Spaans