[lkml]   [2021]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH v3 1/2] mempinfd: Add new syscall to provide memory pin
On Sun, Feb 07, 2021 at 10:24:28PM +0000, Song Bao Hua (Barry Song) wrote:
> > > In high-performance I/O cases, accelerators might want to perform
> > > I/O on a memory without IO page faults which can result in dramatically
> > > increased latency. Current memory related APIs could not achieve this
> > > requirement, e.g. mlock can only avoid memory to swap to backup device,
> > > page migration can still trigger IO page fault.
> >
> > Well ... we have two requirements. The application wants to not take
> > page faults. The system wants to move the application to a different
> > NUMA node in order to optimise overall performance. Why should the
> > application's desires take precedence over the kernel's desires? And why
> > should it be done this way rather than by the sysadmin using numactl to
> > lock the application to a particular node?
> NUMA balancer is just one of many reasons for page migration. Even one
> simple alloc_pages() can cause memory migration in just single NUMA
> node or UMA system.
> The other reasons for page migration include but are not limited to:
> * memory move due to CMA
> * memory move due to huge pages creation
> Hardly we can ask users to disable the COMPACTION, CMA and Huge Page
> in the whole system.

You're dodging the question. Should the CMA allocation fail because
another application is using SVA?

I would say no. The application using SVA should take the one-time
performance hit from having its memory moved around.

 \ /
  Last update: 2021-02-08 02:33    [W:0.100 / U:2.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site