linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Xishi Qiu <qiuxishi@huawei.com>
Cc: Andi Kleen <andi@firstfloor.org>,
	Fengguang Wu <fengguang.wu@intel.com>,
	Simon Jeons <simon.jeons@gmail.com>,
	Wanpeng Li <liwanp@linux.vnet.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	WuJianguo <wujianguo@huawei.com>, Liujiang <jiang.liu@huawei.com>,
	Vyacheslav.Dubeyko@huawei.com, Borislav Petkov <bp@alien8.de>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	wency@cn.fujitsu.com, Hanjun Guo <guohanjun@huawei.com>
Subject: Re: [PATCH V2] MCE: fix an error of mce_bad_pages statistics
Date: Tue, 11 Dec 2012 04:36:59 +0100	[thread overview]
Message-ID: <20121211033659.GA16230@one.firstfloor.org> (raw)
In-Reply-To: <50C6A7BC.8010200@huawei.com>

> "There are not so many free pages in a typical server system", sorry I don't
> quite understand it.

Linux tries to keep most memory in caches. As Linus says "free memory is
bad memory"

>
> buffered_rmqueue()
> 	prep_new_page()
> 		check_new_page()
> 			bad_page()
> 
> If we alloc 2^10 pages and one of them is a poisoned page, then the whole 4M
> memory will be dropped.

prep_new_page() is only called on whatever is allocated.
MAX_ORDER is much smaller than 2^10

If you allocate a large order page then yes the complete page is
dropped. This is today generally true in hwpoison. It would be one
possible area of improvement (probably mostly if 1GB pages become
more common than they are today)

It's usually not a problem because usually most allocations are
small order and systems have generally very few memory errors,
and even the largest MAX_ORDER pages are a small fraction of the 
total memory.

If you lose larger amounts of memory usually you quickly hit something
that HWPoison cannot handle.

-Andi

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      reply	other threads:[~2012-12-11  3:37 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-07  8:48 [PATCH V2] MCE: fix an error of mce_bad_pages statistics Xishi Qiu
2012-12-07 14:33 ` Borislav Petkov
2012-12-07 22:11 ` Andrew Morton
2012-12-07 22:41   ` Borislav Petkov
2012-12-10  4:33   ` Xishi Qiu
2012-12-10  8:33   ` Wanpeng Li
2012-12-10  8:33   ` Wanpeng Li
2012-12-10  9:06     ` Xishi Qiu
2012-12-10 10:47       ` Simon Jeons
2012-12-10 11:16         ` Xishi Qiu
2012-12-10 11:39           ` Wanpeng Li
2012-12-10 11:54             ` Xishi Qiu
2012-12-10 12:11               ` Borislav Petkov
2012-12-10 15:39             ` Andi Kleen
2012-12-10 11:39           ` Wanpeng Li
2012-12-10 11:58           ` Simon Jeons
     [not found]           ` <1355140561.1821.5.camel@kernel.cn.ibm.com>
     [not found]             ` <50C5D844.8050707@huawei.com>
2012-12-10 12:47               ` Simon Jeons
2012-12-11  1:16                 ` Wanpeng Li
2012-12-11  6:49                   ` Xishi Qiu
2012-12-11  8:02                     ` Wanpeng Li
2012-12-11  8:02                     ` Wanpeng Li
2012-12-11  1:16                 ` Wanpeng Li
2012-12-10 15:38           ` Andi Kleen
2012-12-11  1:49             ` Simon Jeons
2012-12-11  2:03               ` Andi Kleen
2012-12-11  2:14                 ` Simon Jeons
2012-12-11  3:01                   ` Andi Kleen
2012-12-11  3:13                     ` Simon Jeons
2012-12-11  3:19                       ` Andi Kleen
2012-12-11  3:48                         ` Simon Jeons
2012-12-11  5:55                           ` Xishi Qiu
2012-12-11  6:34                             ` Wanpeng Li
2012-12-11  6:34                             ` Wanpeng Li
2012-12-11  2:25             ` Xishi Qiu
2012-12-11  2:45               ` Fengguang Wu
2012-12-11  2:58                 ` Andi Kleen
2012-12-11  3:25                   ` Xishi Qiu
2012-12-11  3:36                     ` Andi Kleen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121211033659.GA16230@one.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=Vyacheslav.Dubeyko@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=fengguang.wu@intel.com \
    --cc=guohanjun@huawei.com \
    --cc=jiang.liu@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liwanp@linux.vnet.ibm.com \
    --cc=qiuxishi@huawei.com \
    --cc=simon.jeons@gmail.com \
    --cc=wency@cn.fujitsu.com \
    --cc=wujianguo@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).