On 9/24/18 10:14 AM, Michal Hocko wrote:
On Fri 14-09-18 12:01:18, Steven Sistare wrote:
On 9/14/2018 1:56 AM, Michal Hocko wrote:
[...]
Why does this matter for something that is for analysis purposes.
Reading the file for the whole address space is far from a free
operation. Is the page w
On 9/13/2018 5:25 PM, Dave Hansen wrote:
On 09/13/2018 05:10 PM, Andrew Morton wrote:
Also, VMAs having THP pages can have a mix of 4k pages and hugepages.
The page walks would be efficient in scanning and determining if it is
a THP huge page and step over it. Whereas using the API, the applicat
On 9/14/18 5:49 AM, Jann Horn wrote:
On Fri, Sep 14, 2018 at 8:21 AM Michal Hocko wrote:
On Fri 14-09-18 03:33:28, Jann Horn wrote:
On Wed, Sep 12, 2018 at 10:43 PM prakash.sangappa
wrote:
On 05/09/2018 04:31 PM, Dave Hansen wrote:
On 05/07/2018 06:16 PM, prakash.sangappa wrote:
It will
On 9/14/18 9:01 AM, Steven Sistare wrote:
On 9/14/2018 1:56 AM, Michal Hocko wrote:
On Thu 13-09-18 15:32:25, prakash.sangappa wrote:
The proc interface provides an efficient way to export address range
to numa node id mapping information compared to using the API.
Do you have any numbers?
048 N2
0048-00481000 -
00481000-004a N0
004a-004a2000 -
004a2000-004aa000 N2
004aa000-004ad000 N0
004ad000-004ae000 -
..
Signed-off-by: Prakash Sangappa
Reviewed-by: Steve Sistare
---
fs/proc/task_mmu.c | 158 +
1 file ch
Add support to check if numa node id matches when gathering pte stats,
to be used by later patches.
Signed-off-by: Prakash Sangappa
Reviewed-by: Steve Sistare
---
fs/proc/task_mmu.c | 44 +---
1 file changed, 37 insertions(+), 7 deletions(-)
diff --git
Introduce supporting data structures and file operations. Later
patch will provide changes for generating file content.
Signed-off-by: Prakash Sangappa
Reviewed-by: Steve Sistare
---
fs/proc/base.c | 2 ++
fs/proc/internal.h | 1 +
fs/proc/task_mmu.c | 42
Permission to access /proc//numa_vamaps file should be governed by
PTRACE_READ_REALCREADS check to restrict getting specific VA range to numa
node mapping information.
Signed-off-by: Prakash Sangappa
Reviewed-by: Steve Sistare
---
fs/proc/base.c | 4 +++-
fs/proc/task_mmu.c | 2 +-
2 files
Add documentation for /proc//numa_vamaps in
Documentation/filesystems/proc.txt
Signed-off-by: Prakash Sangappa
Reviewed-by: Steve Sistare
---
Documentation/filesystems/proc.txt | 21 +
1 file changed, 21 insertions(+)
diff --git a/Documentation/filesystems/proc.txt
b
s range to numa node information
can to be read from this file.
The new file /proc//numa_vamaps will be governed by ptrace access
mode PTRACE_MODE_READ_REALCREDS.
See following for previous discussion about this proposal
https://marc.info/?t=15252407341&r=1&w=2
Prakash Sangappa (
Allow lseeking to a process virtual address(VA), starting from where
the address range to numa node information can be read. The lseek offset
will be the process virtual address.
Signed-off-by: Prakash Sangappa
Reviewed-by: Steve Sistare
---
fs/proc/task_mmu.c | 23 ++-
1
On 5/10/18 12:42 AM, Michal Hocko wrote:
On Fri 04-05-18 09:18:11, Prakash Sangappa wrote:
On 5/4/18 4:12 AM, Michal Hocko wrote:
On Thu 03-05-18 15:39:49, prakash.sangappa wrote:
On 05/03/2018 11:03 AM, Christopher Lameter wrote:
On Tue, 1 May 2018, Prakash Sangappa wrote:
For analysis
On 5/4/18 7:57 AM, Christopher Lameter wrote:
On Thu, 3 May 2018, prakash.sangappa wrote:
exact numa node from where the pages have been allocated.
Cant you write a small script that scans the information in numa_maps and
then displays the total pages per NUMA node and then a list of which
r
On 5/4/18 4:12 AM, Michal Hocko wrote:
On Thu 03-05-18 15:39:49, prakash.sangappa wrote:
On 05/03/2018 11:03 AM, Christopher Lameter wrote:
On Tue, 1 May 2018, Prakash Sangappa wrote:
For analysis purpose it is useful to have numa node information
corresponding mapped address ranges of
t=13971872441&r=1&w=2
Signed-off-by: Prakash Sangappa
---
fs/proc/base.c | 2 +
fs/proc/internal.h | 3 +
fs/proc/task_mmu.c | 299 -
3 files changed, 303 insertions(+), 1 deletion(-)
diff --git a/fs/proc/base.c b/fs/proc/b
Resident set size(Rss) accounting of hugetlb pages is not done
currently in /proc//smaps. The pmap command reads rss from
this file and so it shows Rss to be 0 in pmap -x output for
hugetlb mapped vmas. This patch fixes it.
Signed-off-by: Prakash Sangappa
---
fs/proc/task_mmu.c | 1 +
1 file
On 10/17/2017 3:40 PM, Andy Lutomirski wrote:
On Tue, Oct 17, 2017 at 3:35 PM, prakash sangappa
wrote:
On 10/17/2017 3:02 PM, Andy Lutomirski wrote:
On Tue, Oct 17, 2017 at 8:38 AM, Prakash Sangappa
wrote:
On 10/16/17 5:52 PM, Andy Lutomirski wrote:
On Mon, Oct 16, 2017 at 3:54 PM
On 10/17/2017 3:02 PM, Andy Lutomirski wrote:
On Tue, Oct 17, 2017 at 8:38 AM, Prakash Sangappa
wrote:
On 10/16/17 5:52 PM, Andy Lutomirski wrote:
On Mon, Oct 16, 2017 at 3:54 PM, prakash.sangappa
wrote:
On 10/16/2017 03:07 PM, Nagarathnam Muthusamy wrote:
On 10/16/2017 02:36 PM
On 10/16/17 5:52 PM, Andy Lutomirski wrote:
On Mon, Oct 16, 2017 at 3:54 PM, prakash.sangappa
wrote:
On 10/16/2017 03:07 PM, Nagarathnam Muthusamy wrote:
On 10/16/2017 02:36 PM, Andrew Morton wrote:
On Sat, 14 Oct 2017 11:17:47 +0300 Konstantin Khlebnikov
wrote:
pid_t translate_pid(pi
Userfaultfd feature UFFD_FEATURE_SIGBUS was merged recently and should
be available in Linux 4.14 release. This patch is for the manpage
changes documenting this API.
Documents the following commit:
commit 2d6d6f5a09a96cc1fec7ed992b825e05f64cb50e
Author: Prakash Sangappa
Date: Wed Sep 6 16:23
cc: Andrea Arcangeli
On 10/6/17 7:52 PM, Prakash Sangappa wrote:
Userfaultfd feature UFFD_FEATURE_SIGBUS was merged recently and should
be available in Linux 4.14 release. This patch is for the manpage
changes documenting this API.
Documents the following commit:
commit
Userfaultfd feature UFFD_FEATURE_SIGBUS was merged recently and should
be available in Linux 4.14 release. This patch is for the manpage
changes documenting this API.
Documents the following commit:
commit 2d6d6f5a09a96cc1fec7ed992b825e05f64cb50e
Author: Prakash Sangappa
Date: Wed Sep 6 16:23
On 8/30/17 10:41 AM, ebied...@xmission.com wrote:
Prakash Sangappa writes:
With regards to security, the question basically is what is the consequence
of passing the wrong id. As I understand it, Interpreting the id to be pid
or tid, the effective uid and gid will be the same. It would be
ucred.
Signed-off-by: Prakash Sangappa
---
net/core/scm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/scm.c b/net/core/scm.c
index b1ff8a4..9274197 100644
--- a/net/core/scm.c
+++ b/net/core/scm.c
@@ -55,6 +55,7 @@ static __inline__ int scm_check_creds(struct ucred *creds
ucred.
Signed-off-by: Prakash Sangappa
---
net/core/scm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/scm.c b/net/core/scm.c
index b1ff8a4..9274197 100644
--- a/net/core/scm.c
+++ b/net/core/scm.c
@@ -55,6 +55,7 @@ static __inline__ int scm_check_creds(struct ucred *creds
d'
is leaked.
Signed-off-by: Prakash Sangappa
---
Change log
v3: Eliminated use of sig_repeat variable and simplified error return.
v2:
- Added comments to explain the tests.
- Fixed test to fail immediately if signal repeats.
- Addressed other review comments.
v1: https://lkml.org/l
signal.
See following for previous discussion about the database requirement
leading to this proposal as suggested by Andrea.
http://www.spinics.net/lists/linux-mm/msg129224.html
Signed-off-by: Prakash Sangappa
Reviewed-by: Mike Rapoport
Reviewed-by: Andrea Arcangeli
---
fs/userfaultfd.c
Resending, Andrew asked if I could resend the whole set.
Just added 'Reviewed-by' to commit log for 1/2, no other
changes.
v3 patch for 2/2 as before
http://marc.info/?l=linux-mm&m=150148267803458&w=2
Previous patch set here:
http://marc.info/?l=linux-mm&m=150095815413275
On 7/30/17 12:07 AM, Mike Rapoport wrote:
On Thu, Jul 27, 2017 at 10:18:40PM -0400, Prakash Sangappa wrote:
This patch adds tests for UFFD_FEATURE_SIGBUS feature. The
tests will verify signal delivery instead of userfault events.
Also, test use of UFFDIO_COPY to allocate memory and retry
d'
is leaked.
Signed-off-by: Prakash Sangappa
---
Change log
v3: Eliminated use of sig_repeat variable and simplified error return.
v2:
- Added comments to explain the tests.
- Fixed test to fail immediately if signal repeats.
- Addressed other review comments.
v1: https://lkml.org/l
d'
is leaked.
Signed-off-by: Prakash Sangappa
---
Change log
v2:
- Added comments to explain the tests.
- Fixed test to fail immediately if signal repeats.
- Addressed other review comments.
v1: https://lkml.org/lkml/2017/7/26/101
---
tools/testing/selftests/vm/userfaultf
Yes, I will provide a man page update.
-Prakash.
On 7/27/17 4:58 AM, Michal Hocko wrote:
Please do not forget to provide a man page update with clarified
semantic.
On 7/26/17 7:27 AM, Andrea Arcangeli wrote:
On Tue, Jul 25, 2017 at 12:47:42AM -0400, Prakash Sangappa wrote:
Signed-off-by: Prakash Sangappa
---
tools/testing/selftests/vm/userfaultfd.c | 121 +-
1 files changed, 118 insertions(+), 3 deletions(-)
Like Mike
On 7/26/17 12:53 AM, Mike Rapoport wrote:
+
/*
* For non-cooperative userfaultfd test we fork() a process that will
* generate pagefaults, will mremap the area monitored by the
@@ -585,19 +598,54 @@ static int userfaultfd_open(int features)
* The release of the pages currently genera
://www.spinics.net/lists/linux-mm/msg130678.html
Thanks,
Prakash Sangappa (2):
userfaultfd: Add feature to request for a signal delivery
userfaultfd: selftest: Add tests for UFFD_FREATURE_SIGBUS
fs/userfaultfd.c |3 +
include/uapi/linux/userfaultfd.h | 10
signal.
See following for previous discussion about the database requirement
leading to this proposal as suggested by Andrea.
http://www.spinics.net/lists/linux-mm/msg129224.html
Signed-off-by: Prakash Sangappa
---
fs/userfaultfd.c |3 +++
include/uapi/linux/userfaultfd.h
Signed-off-by: Prakash Sangappa
---
tools/testing/selftests/vm/userfaultfd.c | 121 +-
1 files changed, 118 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/vm/userfaultfd.c
b/tools/testing/selftests/vm/userfaultfd.c
index 1eae79a..6a43e84 100644
On 6/30/2017 6:08 AM, Andrea Arcangeli wrote:
On Fri, Jun 30, 2017 at 11:47:35AM +0200, Michal Hocko wrote:
[...]
As an aside, I rememeber that prior to MADV_FREE there was long
discussion about lazy freeing of memory from userspace. Some users
wanted to be signalled when their memory was free
On 6/28/17 6:18 AM, Mike Rapoport wrote:
On Tue, Jun 27, 2017 at 09:01:20AM -0700, Prakash Sangappa wrote:
On 6/27/17 8:35 AM, Mike Rapoport wrote:
On Tue, Jun 27, 2017 at 09:06:43AM +0200, Michal Hocko wrote:
This is an user visible API so let's CC linux-api mailing list.
On Mon 26-
On 6/20/17 4:35 PM, Prakash Sangappa wrote:
On 6/16/17 6:15 AM, Andrea Arcangeli wrote:
Adding a single if (ctx->feature & UFFD_FEATURE_SIGBUS) goto out,
branch for this corner case to handle_userfault() isn't great and the
hugetlbfs mount option is absolutely zero
On 6/27/17 8:35 AM, Mike Rapoport wrote:
On Tue, Jun 27, 2017 at 09:06:43AM +0200, Michal Hocko wrote:
This is an user visible API so let's CC linux-api mailing list.
On Mon 26-06-17 12:46:13, Prakash Sangappa wrote:
In some cases, userfaultfd mechanism should just deliver a SIGBUS sign
On 6/27/17 12:06 AM, Michal Hocko wrote:
This is an user visible API so let's CC linux-api mailing list.
On Mon 26-06-17 12:46:13, Prakash Sangappa wrote:
In some cases, userfaultfd mechanism should just deliver a SIGBUS signal
to the faulting process, instead of the page-fault event. De
In some cases, userfaultfd mechanism should just deliver a SIGBUS signal
to the faulting process, instead of the page-fault event. Dealing with
page-fault event using a monitor thread can be an overhead in these
cases. For example applications like the database could use the signaling
mechanism fo
On 6/16/17 6:15 AM, Andrea Arcangeli wrote:
Hello Prakash,
Thanks for you response. Comments inline.
On Tue, May 09, 2017 at 01:59:34PM -0700, Prakash Sangappa wrote:
On 5/9/17 1:58 AM, Christoph Hellwig wrote:
On Mon, May 08, 2017 at 03:12:42PM -0700, prakash.sangappa wrote
On 5/9/17 1:59 PM, Prakash Sangappa wrote:
On 5/9/17 1:58 AM, Christoph Hellwig wrote:
On Mon, May 08, 2017 at 03:12:42PM -0700, prakash.sangappa wrote:
Regarding #3 as a general feature, do we want to
consider this and the complexity associated with the
implementation?
We have to. Given
On 5/9/17 1:58 AM, Christoph Hellwig wrote:
On Mon, May 08, 2017 at 03:12:42PM -0700, prakash.sangappa wrote:
Regarding #3 as a general feature, do we want to
consider this and the complexity associated with the
implementation?
We have to. Given that no one has exclusive access to hugetlbfs
On 5/3/17 12:02 PM, Prakash Sangappa wrote:
On 5/2/17 4:43 PM, Dave Hansen wrote:
Ideally, it would be something that is *not* specifically for hugetlbfs.
MADV_NOAUTOFILL, for instance, could be defined to SIGSEGV whenever
memory is touched that was not populated with MADV_WILLNEED, mlock
On 5/2/17 4:43 PM, Dave Hansen wrote:
On 05/02/2017 04:34 PM, Prakash Sangappa wrote:
Similarly, a madvise() option also requires additional system call by every
process mapping the file, this is considered a overhead for the database.
How long-lived are these processes? For a database, I&#
On 5/2/17 2:32 PM, Dave Hansen wrote:
On 05/01/2017 11:00 AM, Prakash Sangappa wrote:
This patch adds a new hugetlbfs mount option 'noautofill', to indicate that
pages should not be allocated at page fault time when accessed thru mmapped
address.
I think the main argument aga
On 5/2/17 3:53 AM, Anshuman Khandual wrote:
On 05/01/2017 11:30 PM, Prakash Sangappa wrote:
Some applications like a database use hugetblfs for performance
reasons. Files on hugetlbfs filesystem are created and huge pages
allocated using fallocate() API. Pages are deallocated/freed using
Some applications like a database use hugetblfs for performance
reasons. Files on hugetlbfs filesystem are created and huge pages
allocated using fallocate() API. Pages are deallocated/freed using
fallocate() hole punching support that has been added to hugetlbfs.
These files are mmapped and acces
51 matches
Mail list logo
