Re: [PATCH v1 1/2] pid: add pidfd_open()

2019-05-18 Thread Joel Fernandes
Hi Christian, For next revision, could you also CC sur...@google.com as well? He is also working on the low memory killer. And also suggest CC to kernel-t...@android.com. And mentioned some comments below, thanks. On Thu, May 16, 2019 at 03:59:42PM +0200, Christian Brauner wrote: [snip] > diff

Re: [PATCH v2 2/2] mm: speed up mremap by 500x on large regions

2018-10-13 Thread Joel Fernandes
On Fri, Oct 12, 2018 at 07:25:08PM -0700, Daniel Colascione wrote: [...] > > But anyway, I think this runtime detection thing is not needed. THP is > > actually expected to be as fast as this anyway, so if that's available then > > we should already be as fast. > > Ah, I think the commit message

Re: [PATCH v2 2/2] mm: speed up mremap by 500x on large regions

2018-10-12 Thread Joel Fernandes
On Fri, Oct 12, 2018 at 06:54:33PM -0700, Daniel Colascione wrote: > I wonder whether it makes sense to expose to userspace somehow whether > mremap is "fast" for a particular architecture. If a feature relies on > fast mremap, it might be better for some userland component to disable > that

Re: [PATCH v2 2/2] mm: speed up mremap by 500x on large regions

2018-10-12 Thread Joel Fernandes
On Fri, Oct 12, 2018 at 06:39:45PM -0700, Daniel Colascione wrote: > Not 32-bit ARM? Well, I didn't want to enable every possible architecture we could in a single go. Certainly arm32 can be a follow on enablement as can be other architectures. The point of this series is to upstream this feature

Re: [PATCH v2 2/2] mm: speed up mremap by 500x on large regions

2018-10-12 Thread Joel Fernandes
On Fri, Oct 12, 2018 at 11:18:36AM -0700, David Miller wrote: > From: Joel Fernandes [...] > > Also, do we not flush the caches from any path when we munmap > > address space? We do call do_munmap on the old mapping from mremap > > after moving to the new one. > > S