From: Srikar Dronamraju <srikar@linux•vnet.ibm.com>
To: Vlastimil Babka <vbabka@suse•cz>
Cc: Sachin Sant <sachinp@linux•vnet.ibm.com>,
Nathan Lynch <nathanl@linux•ibm.com>,
Mel Gorman <mgorman@techsingularity•net>,
Michal Hocko <mhocko@kernel•org>,
Pekka Enberg <penberg@kernel•org>,
linux-mm@kvack•org, Kirill Tkhai <ktkhai@virtuozzo•com>,
David Rientjes <rientjes@google•com>,
Christopher Lameter <cl@linux•com>,
bharata@linux•ibm.com, linuxppc-dev@lists•ozlabs.org,
Joonsoo Kim <iamjoonsoo.kim@lge•com>
Subject: Re: [RFC 1/2] mm, slub: prevent kmalloc_node crashes and memory leaks
Date: Fri, 20 Mar 2020 15:40:06 +0530 [thread overview]
Message-ID: <20200320100950.GA12944@linux.vnet.ibm.com> (raw)
In-Reply-To: <90075919-dd9b-e38a-47a8-aea8520b3b94@suse.cz>
* Vlastimil Babka <vbabka@suse•cz> [2020-03-20 09:43:11]:
> On 3/20/20 8:46 AM, Srikar Dronamraju wrote:
> > * Vlastimil Babka <vbabka@suse•cz> [2020-03-19 15:10:19]:
> >
> >> On 3/19/20 3:05 PM, Srikar Dronamraju wrote:
> >> > * Vlastimil Babka <vbabka@suse•cz> [2020-03-19 14:47:58]:
> >> >
> >>
> >> No, but AFAICS, such node values are already handled in ___slab_alloc, and
> >> cannot reach get_partial(). If you see something I missed, please do tell.
> >>
> >
> > Ah I probably got confused with your previous version where
> > alloc_slab_page() was modified. I see no problems with this version.
>
> Thanks!
>
> > Sorry for the noise.
>
> No problem.
>
> > A question just for my better understanding,
> > How worse would it be to set node to numa_mem_id() instead of NUMA_NODE_ID
> > when the current node is !N_NORMAL_MEMORY?
>
Yes,
> (I'm assuming you mean s/NUMA_NODE_ID/NUMA_NO_NODE/)
>
> Well, numa_mem_id() should work too, but it would make the allocation
> constrained to the node of current cpu, with all the consequences (deactivating
> percpu slab if it was from a different node etc).
>
> There's no reason why this cpu's node should be the closest node to the one that
> was originally requested (but has no memory), so it's IMO pointless or even
> suboptimal to constraint to it. This can be revisited in case we get guaranteed
> existence of node data with zonelists for all possible nodes, but for now
> NUMA_NO_NODE seems the most reasonable fix to me.
>
Okay.
--
Thanks and Regards
Srikar Dronamraju
next prev parent reply other threads:[~2020-03-20 10:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-18 14:42 [RFC 1/2] mm, slub: prevent kmalloc_node crashes and memory leaks Vlastimil Babka
2020-03-18 16:06 ` Bharata B Rao
2020-03-18 16:10 ` Vlastimil Babka
2020-03-18 16:51 ` Vlastimil Babka
2020-03-19 8:52 ` Sachin Sant
2020-03-19 13:23 ` Vlastimil Babka
2020-03-19 13:26 ` Sachin Sant
2020-03-19 13:47 ` Vlastimil Babka
2020-03-19 14:05 ` Srikar Dronamraju
2020-03-19 14:10 ` Vlastimil Babka
2020-03-20 7:46 ` Srikar Dronamraju
2020-03-20 8:43 ` Vlastimil Babka
2020-03-20 10:10 ` Srikar Dronamraju [this message]
2020-03-19 14:59 ` Sachin Sant
2020-03-20 3:42 ` Bharata B Rao
2020-03-20 8:37 ` Vlastimil Babka
2020-03-20 8:44 ` Bharata B Rao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200320100950.GA12944@linux.vnet.ibm.com \
--to=srikar@linux$(echo .)vnet.ibm.com \
--cc=bharata@linux$(echo .)ibm.com \
--cc=cl@linux$(echo .)com \
--cc=iamjoonsoo.kim@lge$(echo .)com \
--cc=ktkhai@virtuozzo$(echo .)com \
--cc=linux-mm@kvack$(echo .)org \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=mgorman@techsingularity$(echo .)net \
--cc=mhocko@kernel$(echo .)org \
--cc=nathanl@linux$(echo .)ibm.com \
--cc=penberg@kernel$(echo .)org \
--cc=rientjes@google$(echo .)com \
--cc=sachinp@linux$(echo .)vnet.ibm.com \
--cc=vbabka@suse$(echo .)cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox