All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sandipan Das <sandipan@linux.ibm.com>
To: David Rientjes <rientjes@google.com>
Cc: Mina Almasry <almasrymina@google.com>,
	mike.kravetz@oracle.com, shakeelb@google.com, shuah@kernel.org,
	gthelen@google.com, akpm@linux-foundation.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org, cgroups@vger.kernel.org,
	aneesh.kumar@linux.vnet.ibm.com
Subject: Re: [PATCH v10 7/8] hugetlb_cgroup: Add hugetlb_cgroup reservation tests
Date: Thu, 30 Jan 2020 11:41:15 +0530	[thread overview]
Message-ID: <98c83a41-b864-5950-488c-443f6ef60b91@linux.ibm.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2001291257510.175731@chino.kir.corp.google.com>

Hi David,

On 30/01/20 2:30 am, David Rientjes wrote:
> On Thu, 23 Jan 2020, Sandipan Das wrote:
> 
>> For powerpc64, either 16MB/16GB or 2MB/1GB huge pages are supported depending
>> on the MMU type (Hash or Radix). I was just running these tests on a powerpc64
>> system with Hash MMU and ran into problems because the tests assume that the
>> hugepage size is always 2MB. Can you determine the huge page size at runtime?
>>
> 
> I assume this is only testing failures of the tools/testing/selftests 
> additions that hardcode 2MB paths and not a kernel problem?  In other 
> words, you can still boot, reserve, alloc, and free hugetlb pages on ppc 
> after this patchset without using the selftests?
> 

Yes, its just the hardcoded paths. I didn't run into any kernel problems.

- Sandipan


  reply	other threads:[~2020-01-30  6:11 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-15  1:26 [PATCH v10 1/8] hugetlb_cgroup: Add hugetlb_cgroup reservation counter Mina Almasry
2020-01-15  1:26 ` Mina Almasry
2020-01-15  1:26 ` [PATCH v10 2/8] hugetlb_cgroup: add interface for charge/uncharge hugetlb reservations Mina Almasry
2020-01-15  1:26   ` Mina Almasry
2020-01-17 19:26   ` Mike Kravetz
2020-01-17 19:34     ` Mina Almasry
2020-01-17 19:34       ` Mina Almasry
2020-01-29 21:21   ` David Rientjes
2020-01-29 21:21     ` David Rientjes
2020-01-29 21:21     ` David Rientjes
2020-01-30  0:41     ` Mike Kravetz
2020-01-15  1:26 ` [PATCH v10 3/8] hugetlb_cgroup: add reservation accounting for private mappings Mina Almasry
2020-01-15  1:26   ` Mina Almasry
2020-01-17 22:57   ` Mike Kravetz
2020-01-29 21:28   ` David Rientjes
2020-01-29 21:28     ` David Rientjes
2020-01-29 21:28     ` David Rientjes
2020-02-03 23:17     ` Mina Almasry
2020-02-03 23:17       ` Mina Almasry
2020-01-15  1:26 ` [PATCH v10 4/8] hugetlb: disable region_add file_region coalescing Mina Almasry
2020-01-15  1:26   ` Mina Almasry
2020-01-21 18:50   ` Mike Kravetz
2020-01-15  1:26 ` [PATCH v10 5/8] hugetlb_cgroup: add accounting for shared mappings Mina Almasry
2020-01-15  1:26   ` Mina Almasry
2020-01-15  1:26 ` [PATCH v10 6/8] hugetlb_cgroup: support noreserve mappings Mina Almasry
2020-01-15  1:26   ` Mina Almasry
2020-01-15  1:26   ` Mina Almasry
2020-01-15  1:26 ` [PATCH v10 7/8] hugetlb_cgroup: Add hugetlb_cgroup reservation tests Mina Almasry
2020-01-15  1:26   ` Mina Almasry
2020-01-23  9:15   ` Sandipan Das
2020-01-23  9:15     ` Sandipan Das
2020-01-23 20:05     ` Mina Almasry
2020-01-23 20:05       ` Mina Almasry
2020-01-29 21:00     ` David Rientjes
2020-01-29 21:00       ` David Rientjes
2020-01-29 21:00       ` David Rientjes
2020-01-30  6:11       ` Sandipan Das [this message]
2020-02-03 23:18         ` Mina Almasry
2020-02-03 23:18           ` Mina Almasry
2020-02-03 23:18           ` Mina Almasry
2020-01-15  1:26 ` [PATCH v10 8/8] hugetlb_cgroup: Add hugetlb_cgroup reservation docs Mina Almasry
2020-01-15  1:26   ` Mina Almasry
2020-01-16 22:44 ` [PATCH v10 1/8] hugetlb_cgroup: Add hugetlb_cgroup reservation counter Mike Kravetz
2020-01-16 22:44   ` Mike Kravetz
2020-01-29 21:09 ` David Rientjes
2020-01-29 21:09   ` David Rientjes
2020-01-29 21:09   ` David Rientjes
2020-02-03 23:16   ` Mina Almasry
2020-02-03 23:16     ` Mina Almasry
2020-02-03 23:16     ` Mina Almasry

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=98c83a41-b864-5950-488c-443f6ef60b91@linux.ibm.com \
    --to=sandipan@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=almasrymina@google.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=cgroups@vger.kernel.org \
    --cc=gthelen@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=rientjes@google.com \
    --cc=shakeelb@google.com \
    --cc=shuah@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.