Re: [PATCH 5/8] mm: move lazily freed pages to inactive list

> Even if we're wrong about the aging of those MADV_FREE pages, their > contents are invalidated; they can be discarded freely, and restoring > them is a mere GFP_ZERO allocation. All other anonymous pages have to > be written to disk, and potentially be read back. > > [ Arguably, MADV_FREE pages

Re: [PATCH v2 01/13] mm: support madvise(MADV_FREE)

> With enough pages at once, though, munmap would be fine, too. That implies lots of page faults and zeroing though. The zeroing alone is a major performance issue. There are separate issues with munmap since it ends up resulting in a lot more virtual memory fragmentation. It would help if the

Re: [PATCH 5/8] mm: move lazily freed pages to inactive list

>>> It probably makes sense to stop thinking about them as anonymous pages >>> entirely at this point when it comes to aging. They're really not. The >>> LRU lists are split to differentiate access patterns and cost of page >>> stealing (and restoring). From that angle, MADV_FREE pages really have

Re: [PATCH 5/8] mm: move lazily freed pages to inactive list

> From a user perspective, it doesn't depend on swap. It's just slower > without swap because it does what MADV_DONTNEED does. The current > implementation can be dropped in where MADV_DONTNEED was previously used. It just wouldn't replace existing layers of purging logic until that edge case is

Re: [PATCH 0/8] MADV_FREE support

e of userland people who want to use >>the syscall. >> >> A few month ago, Daniel Micay(jemalloc active contributor) requested me >> to make progress upstreaming but I was busy at that time so it took >> so long time for me to revist the code and finally, I clean i

[tip:core/urgent] stackprotector: Increase the per-task stack canary's random range from 32 bits to 64 bits on 64-bit platforms

Commit-ID: 5ea30e4e58040cfd6434c2f33dc3ea76e2c15b05 Gitweb: http://git.kernel.org/tip/5ea30e4e58040cfd6434c2f33dc3ea76e2c15b05 Author: Daniel Micay <danielmi...@gmail.com> AuthorDate: Thu, 4 May 2017 09:32:09 -0400 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Fri, 5

[tip:core/urgent] stackprotector: Increase the per-task stack canary's random range from 32 bits to 64 bits on 64-bit platforms

Commit-ID: 5ea30e4e58040cfd6434c2f33dc3ea76e2c15b05 Gitweb: http://git.kernel.org/tip/5ea30e4e58040cfd6434c2f33dc3ea76e2c15b05 Author: Daniel Micay AuthorDate: Thu, 4 May 2017 09:32:09 -0400 Committer: Ingo Molnar CommitDate: Fri, 5 May 2017 08:05:13 +0200 stackprotector: Increase

<    1   2   3   4