On Tue, May 09, 2017 at 11:18:23AM +0200, Michal Hocko wrote:
> On Mon 08-05-17 02:58:36, Naoya Horiguchi wrote:
> > On Tue, May 02, 2017 at 08:55:07PM +0200, Michal Hocko wrote:
> > > On Tue 02-05-17 16:59:30, Laurent Dufour wrote:
> > > > On 28/04/2017 15:48, Michal Hocko wrote:
> > > [...]
> > >
On Mon 08-05-17 02:58:36, Naoya Horiguchi wrote:
> On Tue, May 02, 2017 at 08:55:07PM +0200, Michal Hocko wrote:
> > On Tue 02-05-17 16:59:30, Laurent Dufour wrote:
> > > On 28/04/2017 15:48, Michal Hocko wrote:
> > [...]
> > > > This is getting quite hairy. What is the expected page count of the
>
On Mon, 2017-05-08 at 12:42 +0200, Laurent Dufour wrote:
> Sorry Balbir,
>
> You pointed this out since the beginning but I missed your comment.
> My mistake.
>
No worries, as long as the right thing gets in
Balbir Singh
On 04/05/2017 03:21, Balbir Singh wrote:
>> @@ -5527,7 +5527,7 @@ static void uncharge_list(struct list_head *page_list)
>> next = page->lru.next;
>>
>> VM_BUG_ON_PAGE(PageLRU(page), page);
>> -VM_BUG_ON_PAGE(page_count(page), page);
>> +VM_BUG_ON
On Tue, May 02, 2017 at 08:55:07PM +0200, Michal Hocko wrote:
> On Tue 02-05-17 16:59:30, Laurent Dufour wrote:
> > On 28/04/2017 15:48, Michal Hocko wrote:
> [...]
> > > This is getting quite hairy. What is the expected page count of the
> > > hwpoison page?
>
> OK, so from the quick check of the
> @@ -5527,7 +5527,7 @@ static void uncharge_list(struct list_head *page_list)
> next = page->lru.next;
>
> VM_BUG_ON_PAGE(PageLRU(page), page);
> - VM_BUG_ON_PAGE(page_count(page), page);
> + VM_BUG_ON_PAGE(!PageHWPoison(page) && page_count(pag
On 02/05/2017 20:55, Michal Hocko wrote:
> On Tue 02-05-17 16:59:30, Laurent Dufour wrote:
>> On 28/04/2017 15:48, Michal Hocko wrote:
> [...]
>>> This is getting quite hairy. What is the expected page count of the
>>> hwpoison page?
>
> OK, so from the quick check of the hwpoison code it seems th
On Tue 02-05-17 16:59:30, Laurent Dufour wrote:
> On 28/04/2017 15:48, Michal Hocko wrote:
[...]
> > This is getting quite hairy. What is the expected page count of the
> > hwpoison page?
OK, so from the quick check of the hwpoison code it seems that the ref
count will be > 1 (from get_hwpoison_pa
On 28/04/2017 15:48, Michal Hocko wrote:
> On Fri 28-04-17 11:17:34, Laurent Dufour wrote:
>> On 28/04/2017 09:31, Michal Hocko wrote:
>>> [CC Johannes and Vladimir - the patch is
>>> http://lkml.kernel.org/r/1493130472-22843-2-git-send-email-lduf...@linux.vnet.ibm.com]
>>>
>>> On Fri 28-04-17 08:0
On Fri 28-04-17 11:17:34, Laurent Dufour wrote:
> On 28/04/2017 09:31, Michal Hocko wrote:
> > [CC Johannes and Vladimir - the patch is
> > http://lkml.kernel.org/r/1493130472-22843-2-git-send-email-lduf...@linux.vnet.ibm.com]
> >
> > On Fri 28-04-17 08:07:55, Michal Hocko wrote:
> >> On Thu 27-04
On 26/04/2017 10:59, Balbir Singh wrote:
> On Wed, 2017-04-26 at 04:46 +, Naoya Horiguchi wrote:
>> On Wed, Apr 26, 2017 at 01:45:00PM +1000, Balbir Singh wrote:
>> static int delete_from_lru_cache(struct page *p)
>> {
>> +if (memcg_kmem_enabled())
>> +
On 28/04/2017 09:31, Michal Hocko wrote:
> [CC Johannes and Vladimir - the patch is
> http://lkml.kernel.org/r/1493130472-22843-2-git-send-email-lduf...@linux.vnet.ibm.com]
>
> On Fri 28-04-17 08:07:55, Michal Hocko wrote:
>> On Thu 27-04-17 13:51:23, Andi Kleen wrote:
>>> Michal Hocko writes:
>>
[CC Johannes and Vladimir - the patch is
http://lkml.kernel.org/r/1493130472-22843-2-git-send-email-lduf...@linux.vnet.ibm.com]
On Fri 28-04-17 08:07:55, Michal Hocko wrote:
> On Thu 27-04-17 13:51:23, Andi Kleen wrote:
> > Michal Hocko writes:
> >
> > > On Tue 25-04-17 16:27:51, Laurent Dufour
On Thu 27-04-17 13:51:23, Andi Kleen wrote:
> Michal Hocko writes:
>
> > On Tue 25-04-17 16:27:51, Laurent Dufour wrote:
> >> When page are poisoned, they should be uncharged from the root memory
> >> cgroup.
> >>
> >> This is required to avoid a BUG raised when the page is onlined back:
> >> BU
Michal Hocko writes:
> On Tue 25-04-17 16:27:51, Laurent Dufour wrote:
>> When page are poisoned, they should be uncharged from the root memory
>> cgroup.
>>
>> This is required to avoid a BUG raised when the page is onlined back:
>> BUG: Bad page state in process mem-on-off-test pfn:7ae3b
>> p
On Tue 25-04-17 16:27:51, Laurent Dufour wrote:
> When page are poisoned, they should be uncharged from the root memory
> cgroup.
>
> This is required to avoid a BUG raised when the page is onlined back:
> BUG: Bad page state in process mem-on-off-test pfn:7ae3b
> page:f1eb8ec0 count:0 ma
On Wed, 2017-04-26 at 04:46 +, Naoya Horiguchi wrote:
> On Wed, Apr 26, 2017 at 01:45:00PM +1000, Balbir Singh wrote:
> > > > > static int delete_from_lru_cache(struct page *p)
> > > > > {
> > > > > + if (memcg_kmem_enabled())
> > > > > + memcg_kmem_uncharge(p, 0);
> > > > > +
On Wed, Apr 26, 2017 at 01:45:00PM +1000, Balbir Singh wrote:
> > > > static int delete_from_lru_cache(struct page *p)
> > > > {
> > > > + if (memcg_kmem_enabled())
> > > > + memcg_kmem_uncharge(p, 0);
> > > > +
> > >
> > > The changelog is not quite clear, so we are unchargi
> > > static int delete_from_lru_cache(struct page *p)
> > > {
> > > + if (memcg_kmem_enabled())
> > > + memcg_kmem_uncharge(p, 0);
> > > +
> >
> > The changelog is not quite clear, so we are uncharging a page using
> > memcg_kmem_uncharge for a page in swap cache/page cache?
>
> Hi Bal
On Wed, Apr 26, 2017 at 11:54:58AM +1000, Balbir Singh wrote:
> On Tue, 2017-04-25 at 16:27 +0200, Laurent Dufour wrote:
> > When page are poisoned, they should be uncharged from the root memory
> > cgroup.
> >
> > This is required to avoid a BUG raised when the page is onlined back:
> > BUG: Bad
On Tue, 2017-04-25 at 16:27 +0200, Laurent Dufour wrote:
> When page are poisoned, they should be uncharged from the root memory
> cgroup.
>
> This is required to avoid a BUG raised when the page is onlined back:
> BUG: Bad page state in process mem-on-off-test pfn:7ae3b
> page:f1eb8ec0 c
On Tue, Apr 25, 2017 at 04:27:51PM +0200, Laurent Dufour wrote:
> When page are poisoned, they should be uncharged from the root memory
> cgroup.
>
> This is required to avoid a BUG raised when the page is onlined back:
> BUG: Bad page state in process mem-on-off-test pfn:7ae3b
> page:f1e
When page are poisoned, they should be uncharged from the root memory
cgroup.
This is required to avoid a BUG raised when the page is onlined back:
BUG: Bad page state in process mem-on-off-test pfn:7ae3b
page:f1eb8ec0 count:0 mapcount:0 mapping: (null)
index:0x1
flags: 0x380
23 matches
Mail list logo
