use-after-free. There is only a single path that
might really race here and that is the slab hotplug notifier callback
__kmem_cache_shrink (via slab_mem_going_offline_callback) but that path
doesn't really destroy kmem_cache_node data structures.
Thanks!
--
Michal Hocko
SUSE Labs
On Fri 04-10-19 15:32:01, Konstantin Khlebnikov wrote:
>
>
> On 04/10/2019 15.27, Michal Hocko wrote:
> > On Fri 04-10-19 05:10:17, Matthew Wilcox wrote:
> > > On Fri, Oct 04, 2019 at 01:11:06PM +0300, Konstantin Khlebnikov wrote:
> > > > This is very slow
> extreme configurations.
I do agree with Qian. Either it is really helpful (is it? probably on
the number of cpus) and it should be auto-enabled or it should be
dropped altogether. You cannot really expect people know how to enable
this without a deep understanding of the MM internals. Not to mention
all those users using distro kernels/configs.
A config option sounds like a bad way forward.
--
Michal Hocko
SUSE Labs
s might retry more -
e.g. offlining path drains pcp pvces before migrating the range away, if
there are pages still waiting for a worker to drain them then the
migration would fail and we would retry. But this not a correctness
issue.
--
Michal Hocko
SUSE Labs
On Thu 03-10-19 10:00:08, Vlastimil Babka wrote:
> On 10/3/19 12:32 AM, David Rientjes wrote:
> > On Wed, 2 Oct 2019, Michal Hocko wrote:
> >
> >>>> If
> >>>> hugetlb wants to stress this to the fullest extent possible, it already
> >>>&g
t;
> Further discussion is also on the thread ("powerpc: Perform a bounds
> check in arch_add_memory")
> http://lkml.kernel.org/r/20190827052047.31547-1-alast...@au1.ibm.com
>
> Signed-off-by: Alastair D'Silva
I am sorry to come late to the party. This looks better
is bad/unhelpful and why the chnage is
needed. All you claim is that something is a certain way and then assert
that it should be done differently. That is not how changelogs should
look like.
--
Michal Hocko
SUSE Labs
h
> faster because it would be done in one go. Users who allocate through the
> kernel command line would obviously be unaffected.
Requesting the userspace to drop _all_ page cache in order allocate a
number of hugetlb pages or any other affected __GFP_RETRY_MAYFAIL
requests is simply not reasonable IMHO.
--
Michal Hocko
SUSE Labs
not used these days.
> Cc: Mel Gorman
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Signed-off-by: Yang Shi
Acked-by: Michal Hocko
Thanks!
> ---
> mm/vmscan.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> i
etected
> --
I pressume the deadlock is real. If that is the case then Cc: stable and
Fixes tag would be really appreciated.
> Signed-off-by: Qian Cai
Anyway, I do agree that this is the right thing to do. With the improved
changelog, fi
gt; + * order, fail immediately unless the allocator has
> + * requested compaction and reclaim retry.
>*
>* Reclaim is
>* - potentially very expensive because zones are far
--
Michal Hocko
SUSE Labs
s, because load
> XYZ".
>
> And I don't mean microbenchmark numbers for "look, behavior changed".
> I mean "look, this is a real load, and now it runs X% slower because
> it relied on this hugetlbfs behavior".
It is not about running slower. It is about not getting the expected
amount of hugetlb pages requested by admin who knows that that size is
needed.
--
Michal Hocko
SUSE Labs
inting at during the review and those concerns were never really
addressed before merging.
In any case this is something to be fixed ASAP. Do you have any better
proposa? I do not assume you would be proposing yet another revert.
--
Michal Hocko
SUSE Labs
bout this getting more and more complex
(http://lkml.kernel.org/r/20191002084014.gh15...@dhcp22.suse.cz) holds
here even more. Can we step back and reconsider the whole thing please?
> [1]: https://lore.kernel.org/lkml/20190930084604.GC17687@shao2-debian/
>
> Cc: Kirill A. Shutemov
> Cc
ve any numbers on the effect of this patch.
Btw. the whole thing is getting more and more complex and I still
believe the approach is just wrong. We are tunning for something that
doesn't really belong to the memory reclaim in the first place IMHO.
> Cc: Kirill A. Shutemov
> Cc: Kirill
h! I would prefer to move the definition to the
> correct set of #ifdef guards rather than __maybe_unused. Maybe move
> the definition of mem_cgroup_id_get_many() to just before
> __mem_cgroup_clear_mc()? I find __maybe_unused to be a code smell.
Agreed!
--
Michal Hocko
SUSE Labs
MU instead?
I wanted to do that in the past but there was a clear disagreement from
Johannes.
--
Michal Hocko
SUSE Labs
On Tue 01-10-19 07:43:43, Michal Hocko wrote:
[...]
> I also didn't really get to test any NUMA aspect of the change yet. I
> still do hope that David can share something I can play with
> because I do not want to create something completely artificial.
I have split out my kvm machine
On Mon 30-09-19 13:28:17, Michal Hocko wrote:
[...]
> Do not get me wrong, but we have a quite a long history of fine tuning
> for THP by adding kludges here and there and they usually turnout to
> break something else. I really want to get to understand the underlying
> prob
On Sat 28-09-19 13:59:26, Linus Torvalds wrote:
> On Fri, Sep 27, 2019 at 12:48 AM Michal Hocko wrote:
> >
> > - page = get_page_from_freelist(gfp_mask, order, alloc_flags, ac);
> > + if (!order)
> > + page = get_page_from_freelist(gfp_mask,
0
> 26A2379C
>
> Signed-off-by: Qian Cai
Unless I am missing something
Fixes: 8823b1dbc05f ("mm/page_poison.c: enable PAGE_POISONING as a separate
option")
Fixes: 6471384af2a6 ("mm: security: introduce init_on_alloc=1 and
init_on_free=1 boot options")
interrupts, but I think it also needs some sort of
> memory barrier(s), in order to prevent reads of the page table (gup_pgd_range,
> etc) from speculatively happening before the interrupts are disabled.
Could you be more specific about the race scenario please? I thought
that the unmap path
age_from_freelist(gfp_mask, order, alloc_flags, ac);
if (page)
goto got_pg;
The whole point of handling this in the page allocator directly is to
have a unified solutions rather than have each specific caller invent
its own way to achieve higher locality.
--
Michal Hocko
SUSE Labs
On Tue 24-09-19 08:20:22, Alexander Duyck wrote:
> On Tue, Sep 24, 2019 at 7:23 AM Michal Hocko wrote:
> >
> > On Wed 18-09-19 10:52:25, Alexander Duyck wrote:
> > [...]
> > > In order to try and keep the time needed to find a non-reported page to
> > > a m
On Thu 26-09-19 07:19:27, Qian Cai wrote:
>
>
> > On Sep 26, 2019, at 3:26 AM, Michal Hocko wrote:
> >
> > OK, this is using for_each_online_cpu but why is this a problem? Have
> > you checked what the code actually does? Let's say that online_pages is
> >
or
> > b) sit on them for another cycle or
> > c) drop them and ask Chris for a resend so we can start again.
>
> Michal, would you have time to take another look this week? Otherwise,
> I think everyone who would review them has done so.
I do not remember objecting to this particular patch. I also admit I do
not remember much about it either. I am unlikely to get to review this
in more depth these days.
It seems more people have reviewed it already so just go ahead.
--
Michal Hocko
SUSE Labs
g blind in a middle of a
> discussion and
> 2) I got back from holydays yesterday, so bear with me.
>
> Would not be better to just place the check in add_memory_resource instead?
This was the previous version of the patch. The argument is that we do
not want each add_pages user to think of this special handling.
--
Michal Hocko
SUSE Labs
or this path
but no callers seem to be deeply concerned about a specific error codes
so this should be safe.
Acked-by: Michal Hocko
> ---
> mm/memory_hotplug.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>
f __add_pages(int nid, unsigned long pfn,
> > unsigned long nr_pages,
> > unsigned long nr, start_sec, end_sec;
> > struct vmem_altmap *altmap = restrictions->altmap;
> >
> > + err = check_hotplug_memory_addressable(pfn, nr_pages);
> > + if (err)
> > + return err;
> > +
> > if (altmap) {
> > /*
> > * Validate altmap is within bounds of the total request
> >
>
>
> I know Michal suggested this, but I still prefer checking early instead
> of when we're knees-deep into adding of memory.
What is your concern here? Unwinding the state should be pretty
straightfoward from this failure path.
--
Michal Hocko
SUSE Labs
ating cpu and memory hotplug locks was a bad
decision. If there are places which need both they should better use
both lock explicitly.
Now, the reality might turn out more complicated due to locks nesting
but hiding the cpu lock into the mem hotplug is just not fixing that.
--
Michal Hocko
SUSE Labs
On Wed 25-09-19 14:20:59, Qian Cai wrote:
> On Wed, 2019-09-25 at 19:48 +0200, Michal Hocko wrote:
> > On Wed 25-09-19 12:01:02, Qian Cai wrote:
> > > On Wed, 2019-09-25 at 09:02 +0200, David Hildenbrand wrote:
> > > > On 24.09.19 20:54, Qian Cai wrote:
> > >
On Wed 25-09-19 12:01:02, Qian Cai wrote:
> On Wed, 2019-09-25 at 09:02 +0200, David Hildenbrand wrote:
> > On 24.09.19 20:54, Qian Cai wrote:
> > > On Tue, 2019-09-24 at 17:11 +0200, Michal Hocko wrote:
> > > > On Tue 24-09-19 11:03:21, Qian Cai wrote:
On Tue 24-09-19 14:54:04, Qian Cai wrote:
> On Tue, 2019-09-24 at 17:11 +0200, Michal Hocko wrote:
> > On Tue 24-09-19 11:03:21, Qian Cai wrote:
> > [...]
> > > While at it, it might be a good time to rethink the whole locking over
> > > there, as
> > >
Let me revive this thread as there was no follow up.
On Mon 09-09-19 21:30:20, Michal Hocko wrote:
[...]
> I believe it would be the best to start by explaining why we do not see
> the same problem with order-0 requests. We do not enter the slow path
> and thus the memory reclaim if the
On Wed 25-09-19 10:35:30, Hillf Danton wrote:
>
> On Tue, 24 Sep 2019 17:23:35 + from Roman Gushchin
> >
> > On Tue, Sep 24, 2019 at 03:30:16PM +0200, Michal Hocko wrote:
> > >
> > > But really, make sure you look into the existing feature set that memc
> memblock_free()
> memblock_remove()
> ..
> }
>
> [1] https://patchwork.kernel.org/patch/11127623/
>
> Cc: Andrew Morton
> Cc: Oscar Salvador
> Cc: Michal Hocko
> Cc: David Hildenbrand
> Cc: Pavel Tatashin
> Cc:
On Tue 24-09-19 09:26:37, Yang Shi wrote:
>
>
> On 9/24/19 6:56 AM, Michal Hocko wrote:
> > Do we really need this if deferred list is going to be shrunk more
> > pro-actively as discussed already - I am sorry I do not have a link handy
> > but in short the deferred
ould prevent hotremove to continue in the first place.
There are likely details to be checked of course but the lock just seems
bogus.
--
Michal Hocko
SUSE Labs
re this is reasonably reviewable.
So please add some testing results (ideally cpu hotplug racing a lot
with the memory hotplug). Then I would be willing to give this a try
and see. First by keeping it in linux-next for a release or two and then
eyes closed, fingers crossed and go to the wild. Do we have
. This particular patch is quite small
but I am not really supper happy to add more boilerplate code...
> The change that introduced this is here:
> commit 452647784b2fccfdeeb976f6f842c6719fb2daac
> Author: Vladimir Davydov
> Date: Tue Jul 26 15:24:21 2016 -0700
> Although I had the same problem before with other header files.
>
--
Michal Hocko
SUSE Labs
to hear
very convincing arguments about other approaches not being feasible.
There are none in this cover letter unfortunately. This will be really a
hard sell without them.
--
Michal Hocko
SUSE Labs
e convert deferred_split to memcg
> aware in the later patches.
>
> Link:
> http://lkml.kernel.org/r/1565144277-36240-2-git-send-email-yang@linux.alibaba.com
> Signed-off-by: Yang Shi
> Suggested-by: "Kirill A . Shutemov"
> Acked-by: Kirill A. Shutemov
>
On Tue 24-09-19 21:43:52, Baoquan He wrote:
> On 09/24/19 at 03:16pm, Michal Hocko wrote:
> > On Tue 24-09-19 21:04:58, Baoquan He wrote:
> > > On 09/24/19 at 02:27pm, Michal Hocko wrote:
> > > > On Tue 24-09-19 19:11:51, Baoquan He wrote:
> > > > > d
On Tue 24-09-19 15:36:42, Hillf Danton wrote:
>
> On Mon, 23 Sep 2019 21:28:34 Michal Hocko wrote:
> >
> > On Mon 23-09-19 21:04:59, Hillf Danton wrote:
> > >
> > > On Thu, 19 Sep 2019 21:32:31 +0800 Michal Hocko wrote:
> > > >
>
On Tue 24-09-19 21:04:58, Baoquan He wrote:
> On 09/24/19 at 02:27pm, Michal Hocko wrote:
> > On Tue 24-09-19 19:11:51, Baoquan He wrote:
> > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > > index f3c15bb07cce..84e3fdb1ccb4 100644
> > > --- a/mm/memc
t
> page *page,
>
> trace_track_foreign_dirty(page, wb);
>
> + if (mem_cgroup_disabled())
> + return;
> +
This doesn't seem correct. We shouldn't even enter the slowpath with
memcg disabled AFAIC. The check should be done at mem_cgroup_track_foreign_dirty
level.
--
Michal Hocko
SUSE Labs
gt; On Wed, Sep 18, 2019 at 08:49:49PM -0700, Matthew Wilcox wrote:
> >>>> On Thu, Sep 19, 2019 at 10:33:10AM +0800, Lin Feng wrote:
> >>>>> On 9/18/19 20:33, Michal Hocko wrote:
> >>>>>> I absolutely agree here. From you changelog it is also not c
CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
which means CONFIG_MEMCG_KMEM is not enabled as well. And the
compilation succeeds. What is your config file?
--
Michal Hocko
SUSE Labs
On Tue 24-09-19 13:23:49, Peter Zijlstra wrote:
> On Tue, Sep 24, 2019 at 12:56:22PM +0200, Michal Hocko wrote:
[...]
> > To be honest I really fail to see why to object to a simple semantic
> > that NUMA_NO_NODE imply all usable cpus. Could you explain that please?
>
> B
On Tue 24-09-19 09:42:31, Anshuman Khandual wrote:
>
>
> On 09/23/2019 04:24 PM, David Hildenbrand wrote:
> > On 23.09.19 12:52, Michal Hocko wrote:
> >> On Mon 16-09-19 11:17:37, Anshuman Khandual wrote:
> >>> In add_memory_resource() the mem
On Tue 24-09-19 11:13:31, David Hildenbrand wrote:
> On 24.09.19 11:09, Michal Hocko wrote:
> > On Tue 24-09-19 11:31:05, Alastair D'Silva wrote:
> >> On Mon, 2019-09-23 at 14:25 +0200, Michal Hocko wrote:
[...]
> >>> This will result in a silent f
Andrew, do you plan to send this patch to Linus as ell?
On Fri 06-09-19 14:56:08, Michal Hocko wrote:
> From: Michal Hocko
>
> Thomas has noticed the following NULL ptr dereference when using cgroup
> v1 kmem limit:
> BUG: unable to handle kernel NULL pointer dereference at 0
On Tue 24-09-19 11:31:05, Alastair D'Silva wrote:
> On Mon, 2019-09-23 at 14:25 +0200, Michal Hocko wrote:
> > On Tue 17-09-19 11:07:47, Alastair D'Silva wrote:
> > > From: Alastair D'Silva
> > >
> > > On PowerPC, the address ranges allocated to OpenCAPI
ax = 20
Neither of the two values is really insane on 32GB machine.
I am not sure we want/need to tune the max_thread value further. If
anything the tuning should be removed altogether if proven not useful in
general. But we definitely need a way to override this auto-tuning.
Thanks
--
Michal Hocko
SUSE Labs
Isn't this rushed a bit? I've had a review feedback just yesterday
http://lkml.kernel.org/r/20190923122513.go6...@dhcp22.suse.cz and had
some concerns.
> Link: http://lkml.kernel.org/r/20190917010752.28395-2-alast...@au1.ibm.com
> Signed-off-by: Alastair D'Silva
> Reviewed-by: David Hild
re is no way its true.
If you disable highmem then all the 32b kernel can with is lowmem and
that is defined by the split (1/3 low/high).
--
Michal Hocko
SUSE Labs
On Mon 23-09-19 21:04:59, Hillf Danton wrote:
>
> On Thu, 19 Sep 2019 21:32:31 +0800 Michal Hocko wrote:
> >
> > On Thu 19-09-19 21:13:32, Hillf Danton wrote:
> > >
> > > Currently memory controler is playing increasingly important role in
> > > h
On Mon 23-09-19 14:20:05, David Hildenbrand wrote:
> On 23.09.19 14:07, Michal Hocko wrote:
> > On Mon 23-09-19 13:34:18, David Hildenbrand wrote:
> >> On 23.09.19 13:15, Michal Hocko wrote:
> > [...]
> >>> I am wondering why those pages get onlined wh
return 0;
> + return check_hotplug_memory_addressable(start, size);
This will result in a silent failure (unlike misaligned case). Is this
what we want?
> }
>
> static int online_memory_block(struct memory_block *mem, void *arg)
> --
> 2.21.0
>
--
Michal Hocko
SUSE Labs
On Mon 23-09-19 13:34:18, David Hildenbrand wrote:
> On 23.09.19 13:15, Michal Hocko wrote:
[...]
> > I am wondering why those pages get onlined when they are, in fact,
> > supposed to be offline.
> >
>
> It's the current way of emulating sub-memory-block hotplug
On Mon 23-09-19 11:31:30, David Hildenbrand wrote:
> On 23.09.19 10:58, Michal Hocko wrote:
> > On Fri 20-09-19 10:17:54, David Hildenbrand wrote:
> >> On 09.09.19 13:48, David Hildenbrand wrote:
> >>> Based on linux/next + "[PATCH 0/3] Remove __online_page_set_
sk);
> }
> #ifdef CONFIG_COMPAT
> if (unlikely(tsk->compat_robust_list)) {
> compat_exit_robust_list(tsk);
> tsk->compat_robust_list = NULL;
> + exit_pi_state_list(tsk);
> }
> #endif
> - if (unlikely(!list_empty(>pi_state_list)))
> - exit_pi_state_list(tsk);
> #endif
>
> uprobe_free_utask(tsk);
> --
> 2.15.2
>
--
Michal Hocko
SUSE Labs
l problem to solve or this is
an aesthetic matter. Please think of people reading this changelog in
few years and scratching their heads what you were thinking back then...
> Cc: Andrew Morton
> Cc: Oscar Salvador
> Cc: Michal Hocko
> Cc: David Hildenbrand
> Cc: Pavel Tatashin
I'll
> convert this to EXPORT_SYMBOL_GPL now that I know better :)
All other exports in this file are EXPORT_SYMBOL. Why is this one
considered special to restrict the access?
--
Michal Hocko
SUSE Labs
m/memory_hotplug.c| 17 ++---
> > 3 files changed, 4 insertions(+), 20 deletions(-)
> >
>
> Ping, any comments on this one?
Unification makes a lot of sense to me. You can add
Acked-by: Michal Hocko
I will most likely won't surprise if I asked for more he
On Tue 17-09-19 14:35:50, Kirill A. Shutemov wrote:
> On Tue, Sep 17, 2019 at 12:15:19PM +0200, Michal Hocko wrote:
> > On Mon 16-09-19 18:26:19, Kirill A. Shutemov wrote:
> > > On Fri, Sep 13, 2019 at 02:11:19PM -0700, Lucian Adrian Grijincu wrote:
> > > > As page
Andrew, do you want me to send the patch or you can grab it from here?
On Sun 22-09-19 16:24:10, Eric W. Biederman wrote:
> Michal Hocko writes:
>
> > From 711000fdc243b6bc68a92f9ef0017ae495086d39 Mon Sep 17 00:00:00 2001
> > From: Michal Hocko
> > Date: Sun, 22
On Thu 19-09-19 14:33:24, Eric W. Biederman wrote:
> Michal Hocko writes:
>
> > On Tue 17-09-19 12:26:18, Eric W. Biederman wrote:
[...]
> >> Michal is it a very small effect your customers are seeing?
> >> Is it another bug somewhere else?
> >
> >
chin
> Cc: Matthew Wilcox
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Signed-off-by: Hillf Danton
That being said, you should describe the usecase and explain why v2
interface is not providing what you need. We might think about where to
go from there but extending the soft limit reclaim is almost certainly
not the right way to go.
--
Michal Hocko
SUSE Labs
On Thu 19-09-19 09:32:48, Lin Feng wrote:
>
>
> On 9/18/19 20:27, Michal Hocko wrote:
> > Please do not post a new version with a minor compile fixes until there
> > is a general agreement on the approach. Willy had comments which really
> > need to be resolved fi
On Thu 19-09-19 15:46:11, Lin Feng wrote:
>
>
> On 9/19/19 11:49, Matthew Wilcox wrote:
> > On Thu, Sep 19, 2019 at 10:33:10AM +0800, Lin Feng wrote:
> > > On 9/18/19 20:33, Michal Hocko wrote:
> > > > I absolutely agree here. From you
On Wed 18-09-19 09:15:41, Michal Hocko wrote:
> On Tue 17-09-19 12:26:18, Eric W. Biederman wrote:
[...]
> > b) Not being able to bump threads_max to the physical limit of
> >the machine is very clearly a regression.
>
> ... exactly this part. The changelog of the res
are more of "let's
hope it works" kinda thing but making their timeout configurable just
doesn't solve this at all. You are effectively exporting a very subtle
implementation detail into the userspace.
--
Michal Hocko
SUSE Labs
bot
really hold? Because it suggests that the problem has been spotted by
the kbuild bot which is kinda unexpected... I suspect you have just
added that for the minor compilation issue that you have fixed since the
last version.
--
Michal Hocko
SUSE Labs
On Wed 18-09-19 16:02:52, Xiubo Li wrote:
> On 2019/9/18 15:25, Michal Hocko wrote:
> > On Wed 18-09-19 04:58:20, xiu...@redhat.com wrote:
> > > From: Xiubo Li
> > >
> > > The GFP_NOIO means all further allocations will implicitly drop
> > > both __G
d the
> + * the critical section from the allocation recursion point of view. Use
> + * memalloc_noio_restore to end the scope with flags returned by this
> + * function.
> *
> * This function is safe to be used from any context.
> */
> --
> 2.21.0
--
Michal Hocko
SUSE Labs
On Tue 17-09-19 12:26:18, Eric W. Biederman wrote:
> Michal Hocko writes:
>
> > On Tue 17-09-19 17:28:02, Heinrich Schuchardt wrote:
> >>
> >> On 9/17/19 12:03 PM, Michal Hocko wrote:
> >> > Hi,
> >> > I have just stumbled over 16db3d3f117
On Tue 17-09-19 17:28:02, Heinrich Schuchardt wrote:
>
> On 9/17/19 12:03 PM, Michal Hocko wrote:
> > Hi,
> > I have just stumbled over 16db3d3f1170 ("kernel/sysctl.c: threads-max
> > observe limits") and I am really wondering what is the motivation behind
&
er for admins to monitor.
Sure it is not a bug to panic about but it certainly makes life of poor
admins harder.
If there is a pathological THP behavior possible then we should look
into that as well.
--
Michal Hocko
SUSE Labs
On Tue 17-09-19 17:53:57, Yunsheng Lin wrote:
> On 2019/9/17 17:36, Michal Hocko wrote:
> > On Tue 17-09-19 14:20:11, Yunsheng Lin wrote:
> >> On 2019/9/17 13:28, Michael Ellerman wrote:
> >>> Yunsheng Lin writes:
> > [...]
> >>>> But we cannot r
uning from the userspace, just to find out that this is not possible.
Why do we override user admin like that? I find it quite dubious to be
honest. Especially when the auto-tunning is just a very rough estimation
and it seems quite arbitrary.
Thanks
--
Michal Hocko
SUSE Labs
memcontrol: fix swap counter leak on swapout from offline
> cgroup")
> 58fa2a5512d9 ("mm: memcontrol: add sanity checks for memcg->id.ref on
> get/put")
>
> so safe to remove it.
>
> Signed-off-by: Qian Cai
Acked-by: Michal Hocko
> ---
> mm
"cpumask_of_node(%d): node >= nr_node_ids(%u)\n",
> >>node, nr_node_ids);
> >>dump_stack();
> >>return cpu_none_mask;
> >
> > Why do we need this?
>
> As the commit log says, the above cpumask_of_node() is for debugging,
> it should catch other "node < 0" cases except NUMA_NO_NODE.
OK, I would just make it a separate patch.
--
Michal Hocko
SUSE Labs
On Mon 16-09-19 13:11:37, Vlastimil Babka wrote:
> On 9/16/19 12:36 PM, Michal Hocko wrote:
> > On Fri 13-09-19 12:18:49, Kirill A. Shutemov wrote:
> >> Adding fully unmapped pages into deferred split queue is not productive:
> >> these pages are about to be freed or
e changed, 2 insertions(+)
>
> diff --git a/mm/memory.c b/mm/memory.c
> index e0c232fe81d9..55da24f33bc4 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3311,6 +3311,8 @@ vm_fault_t alloc_set_pte(struct vm_fault *vmf, struct
> mem_cgroup *memcg,
> } else {
> inc_mm_counter_fast(vma->vm_mm, mm_counter_file(page));
> page_add_file_rmap(page, false);
> + if (vma->vm_flags & VM_LOCKED && !PageTransCompound(page))
> + mlock_vma_page(page);
> }
> set_pte_at(vma->vm_mm, vmf->address, vmf->pte, entry);
I dunno. Handling it here in alloc_set_pte sounds a bit weird to me.
Altough we already do mlock for CoW pages there, I thought this was more
of an exception.
Is there any real reason why this cannot be done in the standard #PF
path? finish_fault for example?
--
Michal Hocko
SUSE Labs
> + if (nr)
> __mod_node_page_state(page_pgdat(page), NR_ANON_MAPPED, -nr);
> - deferred_split_huge_page(page);
> - }
> }
>
> /**
> --
> 2.21.0
--
Michal Hocko
SUSE Labs
On Wed 11-09-19 22:33:39, Nitin Gupta wrote:
> On Wed, 2019-09-11 at 08:45 +0200, Michal Hocko wrote:
> > On Tue 10-09-19 22:27:53, Nitin Gupta wrote:
> > [...]
> > > > On Tue 10-09-19 13:07:32, Nitin Gupta wrote:
> > > > > For some applicat
On Thu 12-09-19 13:24:25, Kirill A. Shutemov wrote:
> On Thu, Sep 12, 2019 at 11:19:25AM +0200, Michal Hocko wrote:
> > On Wed 11-09-19 08:12:03, Alexander Duyck wrote:
> > > On Wed, Sep 11, 2019 at 4:36 AM Michal Hocko wrote:
> > > >
> > > > On Tu
On Thu 12-09-19 09:47:30, David Hildenbrand wrote:
> On 12.09.19 09:16, Michal Hocko wrote:
> > On Wed 11-09-19 18:09:18, David Hildenbrand wrote:
> >> On 11.09.19 15:51, Michal Hocko wrote:
> >>> On Wed 11-09-19 15:20:02, Michal Hocko wrote:
> >>
On Wed 11-09-19 08:12:03, Alexander Duyck wrote:
> On Wed, Sep 11, 2019 at 4:36 AM Michal Hocko wrote:
> >
> > On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> > [...]
> > > We don't put any limitations on the allocator other then that it needs to
> > &
On Wed 11-09-19 18:09:18, David Hildenbrand wrote:
> On 11.09.19 15:51, Michal Hocko wrote:
> > On Wed 11-09-19 15:20:02, Michal Hocko wrote:
> > [...]
> >>> 4. Continuously report, not the "one time report everything" approach.
> >>
> >&g
On Wed 11-09-19 07:37:40, Andrew Morton wrote:
> On Wed, 11 Sep 2019 14:00:02 +0200 Michal Hocko wrote:
>
> > On Mon 09-09-19 13:22:45, Michal Hocko wrote:
> > > On Fri 06-09-19 11:24:55, Shakeel Butt wrote:
> > [...]
> > > > I wonder what has changed
On Wed 11-09-19 15:20:02, Michal Hocko wrote:
[...]
> > 4. Continuously report, not the "one time report everything" approach.
>
> So you mean the allocator reporting this rather than an external code to
> poll right? I do not know, how much this is nice to have than
On Wed 11-09-19 15:03:39, David Hildenbrand wrote:
> On 11.09.19 14:54, Michal Hocko wrote:
> > On Wed 11-09-19 14:42:41, David Hildenbrand wrote:
> >> On 11.09.19 14:25, Michal Hocko wrote:
> >>> On Wed 11-09-19 14:19:41, Michal Hocko wrote:
> >>>>
On Wed 11-09-19 09:03:10, Michael S. Tsirkin wrote:
> On Wed, Sep 11, 2019 at 02:33:16PM +0200, Michal Hocko wrote:
> > On Wed 11-09-19 08:25:03, Michael S. Tsirkin wrote:
> > > On Wed, Sep 11, 2019 at 02:16:28PM +0200, Michal Hocko wrote:
> > > > On Wed 11-09-19 08:1
On Wed 11-09-19 14:42:41, David Hildenbrand wrote:
> On 11.09.19 14:25, Michal Hocko wrote:
> > On Wed 11-09-19 14:19:41, Michal Hocko wrote:
> >> On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
> >>> On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
&
On Wed 11-09-19 08:25:03, Michael S. Tsirkin wrote:
> On Wed, Sep 11, 2019 at 02:16:28PM +0200, Michal Hocko wrote:
> > On Wed 11-09-19 08:10:00, Michael S. Tsirkin wrote:
> > > iovec addresses coming from vhost are assumed to be
> > > pre-validated, but in fact c
On Wed 11-09-19 14:19:41, Michal Hocko wrote:
> On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
> > On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
> > > On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> > > [...]
> > > > We don't put
On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
> On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
> > On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> > [...]
> > > We don't put any limitations on the allocator other then that it needs to
>
dr - node->start),
> + node->size));
> s += size;
> addr += size;
> ++ret;
> --
> MST
--
Michal Hocko
SUSE Labs
1501 - 1600 of 20557 matches
Mail list logo
