Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1623901

Re: [RFC 1/6] mm, page_alloc: fix more premature OOM due to race with cpuset update

Show all headers | View raw

On Thu, 13 Apr 2017, Vlastimil Babka wrote:

>
> I doubt we can change that now, because that can break existing
> programs. It also makes some sense at least to me, because a task can
> control its own mempolicy (for performance reasons), but cpuset changes
> are admin decisions that the task cannot even anticipate. I think it's
> better to continue working with suboptimal performance than start
> failing allocations?

If the expected semantics (hardwall) are that allocations should fail then
lets be consistent and do so.

Adding more and more exceptions gets this convoluted mess into an even
worse shape. Adding the static binding of nodes was already a screwball
if used within a cpuset because now one has to anticipate how a user would
move the nodes of a cpuset and how the static bindings would work in such
a context.

The admin basically needs to know how the application has used memory
policies if one still wants to move the applications within a cpuset with
the fixed bindings.

Maybe the best way to handle this is to give up on cpuset migration of
live applications? After all this can be done with a script in the same
way as the kernel is doing:

1. Extend the cpuset to include the new nodes.

2. Loop over the processes and use the migrate_pages() to move the apps
one by one.

3. Remove the nodes no longer to be used.

Then forget about translating memory policies. If an application that is
supposed to run in a cpuset and supposed to be moveable has fixed bindings
then the application should be aware of that and be equipped with
some logic to rebind its memory on its own.

Such an application typically already has such logic and executes a
binding after discovering its numa node configuration on startup. It would
have to be modified to redo that action when it gets some sort of a signal
from the script telling it that the node config would be changed.

Having this logic in the application instead of the kernel avoids all the
kernel messes that we keep on trying to deal with and IMHO is much
cleaner.

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[RFC 0/6] cpuset/mempolicies related fixes and cleanups Vlastimil Babka <vbabka@suse.cz> - 2017-04-11 16:10 +0200
  [RFC 4/6] mm, mempolicy: simplify rebinding mempolicies when updating cpusets Vlastimil Babka <vbabka@suse.cz> - 2017-04-11 16:10 +0200
  [RFC 3/6] mm, page_alloc: pass preferred nid instead of zonelist to allocator Vlastimil Babka <vbabka@suse.cz> - 2017-04-11 16:10 +0200
  [RFC 1/6] mm, page_alloc: fix more premature OOM due to race with cpuset update Vlastimil Babka <vbabka@suse.cz> - 2017-04-11 16:10 +0200
    Re: [RFC 1/6] mm, page_alloc: fix more premature OOM due to race  with cpuset update Christoph Lameter <cl@linux.com> - 2017-04-11 19:30 +0200
      Re: [RFC 1/6] mm, page_alloc: fix more premature OOM due to race with  cpuset update Vlastimil Babka <vbabka@suse.cz> - 2017-04-11 21:10 +0200
        Re: [RFC 1/6] mm, page_alloc: fix more premature OOM due to race  with cpuset update Christoph Lameter <cl@linux.com> - 2017-04-12 23:30 +0200
          Re: [RFC 1/6] mm, page_alloc: fix more premature OOM due to race with  cpuset update Vlastimil Babka <vbabka@suse.cz> - 2017-04-13 08:30 +0200
            Re: [RFC 1/6] mm, page_alloc: fix more premature OOM due to race  with cpuset update Christoph Lameter <cl@linux.com> - 2017-04-14 22:40 +0200
    Re: [RFC 1/6] mm, page_alloc: fix more premature OOM due to race with  cpuset update Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2017-04-13 07:50 +0200
      Re: [RFC 1/6] mm, page_alloc: fix more premature OOM due to race with  cpuset update Vlastimil Babka <vbabka@suse.cz> - 2017-04-13 08:10 +0200
        Re: [RFC 1/6] mm, page_alloc: fix more premature OOM due to race with  cpuset update Vlastimil Babka <vbabka@suse.cz> - 2017-04-13 08:10 +0200
  [RFC 6/6] mm, mempolicy: don't check cpuset seqlock where it doesn't matter Vlastimil Babka <vbabka@suse.cz> - 2017-04-11 16:10 +0200

csiph-web