On Tue 27-08-19 10:06:20, Yang Shi wrote:
>
>
> On 8/27/19 5:59 AM, Kirill A. Shutemov wrote:
> > On Tue, Aug 27, 2019 at 03:17:39PM +0300, Kirill A. Shutemov wrote:
> > > On Tue, Aug 27, 2019 at 02:09:23PM +0200, Michal Hocko wrote:
> > > > On Tue 27-0
From: Michal Hocko
Adric Blake has noticed[1] the following warning:
[38491.963105] WARNING: CPU: 7 PID: 175 at mm/vmscan.c:245
set_task_reclaim_state+0x1e/0x40
[...]
[38491.963239] Call Trace:
[38491.963246] mem_cgroup_shrink_node+0x9b/0x1d0
[38491.963250] mem_cgroup_soft_limit_reclaim+0x10c
s.
>
> Signed-off-by: Yi Wang
Acked-by: Michal Hocko
Thanks!
> ---
> mm/oom_kill.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index eda2e2a..65c092e 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kil
it is an option it is a
> > > choice to consider or not.
> >
> > It sounds like you are looking for more of this,
>
> If you want to supplement the OOM Report and keep the information
> together than you could use EBPF to do that. If that really is the
> preference it might make sense to put the entire report as an EBPF
> script than you can modify the script however you choose. That would
> be very flexible. You can change your configuration on the fly. As
> long as it has access to everything you need it should work.
>
> Michal would know what direction OOM is headed and if he thinks that fits with
> where things are headed.
It seems we have landed in the similar thinking here. As mentioned in my
earlier email in this thread I can see the extensibility to be achieved
by eBPF. Essentially we would have a base form of the oom report like
now and scripts would then hook in there to provide whatever a specific
usecase needs. My practical experience with eBPF is close to zero so I
have no idea how that would actually work out though.
[...]
> For production systems installing and updating EBPF scripts may someday
> be very common, but I wonder how data center managers feel about it now?
> Developers are very excited about it and it is a very powerful tool but can I
> get permission to add or replace an existing EBPF on production systems?
I am not sure I understand. There must be somebody trusted to take care
of systems, right?
--
Michal Hocko
SUSE Labs
On Tue 27-08-19 18:07:54, Edward Chron wrote:
> On Tue, Aug 27, 2019 at 12:15 AM Michal Hocko wrote:
> >
> > On Mon 26-08-19 12:36:28, Edward Chron wrote:
> > [...]
> > > Extensibility using OOM debug options
> > > -
>
On Tue 27-08-19 12:00:26, Johannes Weiner wrote:
> On Mon, Aug 26, 2019 at 02:06:30PM +0200, Michal Hocko wrote:
> > On Tue 13-08-19 12:51:43, Michal Hocko wrote:
> > > On Mon 12-08-19 11:07:25, Johannes Weiner wrote:
> > > > On Mon, Aug 12, 2019 at 10:09:
On Tue 27-08-19 19:06:18, Greg KH wrote:
> On Tue, Aug 27, 2019 at 04:10:16PM +0200, Michal Hocko wrote:
> > On Sat 24-08-19 23:23:07, Thomas Backlund wrote:
> > > Den 24-08-2019 kl. 22:57, skrev Andrew Morton:
> > > > On Sat, 17 Aug 2019 19:15:
kpagecgroup_read(struct file *file, char
> __user *buf,
> {
> u64 __user *out = (u64 __user *)buf;
> struct page *ppage;
> + struct zone_range range = { 0, 0 };
> unsigned long src = *ppos;
> unsigned long pfn;
> ssize_t ret = 0;
> @@ -261,7 +323,7 @@ static ssize_t kpagecgroup_read(struct file *file, char
> __user *buf,
> return -EINVAL;
>
> while (count > 0) {
> - if (pfn_valid(pfn))
> + if (pfn_valid(pfn) && pfn_in_zone(pfn, ))
> ppage = pfn_to_page(pfn);
> else
> ppage = NULL;
> --
> 2.18.1
--
Michal Hocko
SUSE Labs
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> > > > for how to do this properly.
> > >
> > > Oh, I'm sorry, will read and follow next time. Thanks!
> >
> > 766a4c19d880 is not present in 5.2 so no -stable backport is needed, yes?
> >
>
> Unfortunately it got added in 5.2.7, so backport is needed.
yet another example of patch not marked for stable backported to the
stable tree. yay...
--
Michal Hocko
SUSE Labs
desirable
http://lkml.kernel.org/r/20190827120335.ga7...@dhcp22.suse.cz
--
Michal Hocko
SUSE Labs
On Tue 27-08-19 20:19:34, Yafang Shao wrote:
> On Tue, Aug 27, 2019 at 8:03 PM Michal Hocko wrote:
> >
> > On Tue 27-08-19 19:56:16, Yafang Shao wrote:
> > > On Tue, Aug 27, 2019 at 7:50 PM Michal Hocko wrote:
> > > >
> > > > On Tue 27-08-19 19:43
On Tue 27-08-19 14:01:56, Vlastimil Babka wrote:
> On 8/27/19 1:02 PM, Kirill A. Shutemov wrote:
> > On Tue, Aug 27, 2019 at 08:01:39AM +0200, Michal Hocko wrote:
> >> On Mon 26-08-19 16:15:38, Kirill A. Shutemov wrote:
> >>>
> >>> Unmapped comple
On Tue 27-08-19 19:56:16, Yafang Shao wrote:
> On Tue, Aug 27, 2019 at 7:50 PM Michal Hocko wrote:
> >
> > On Tue 27-08-19 19:43:49, Yafang Shao wrote:
> > > On Tue, Aug 27, 2019 at 6:43 PM Michal Hocko wrote:
> > > >
> > > > If there are no objec
On Tue 27-08-19 19:43:49, Yafang Shao wrote:
> On Tue, Aug 27, 2019 at 6:43 PM Michal Hocko wrote:
> >
> > If there are no objection to the patch I will post it as a standalong
> > one.
>
> I have no objection to your patch. It could fix the issue.
>
> I still t
On Tue 27-08-19 14:02:10, Kirill A. Shutemov wrote:
> On Tue, Aug 27, 2019 at 08:01:39AM +0200, Michal Hocko wrote:
> > On Mon 26-08-19 16:15:38, Kirill A. Shutemov wrote:
> > > On Mon, Aug 26, 2019 at 09:40:35AM +0200, Michal Hocko wrote:
> > > > On Thu 22-08-19 18:2
If there are no objection to the patch I will post it as a standalong
one.
On Mon 26-08-19 12:55:21, Michal Hocko wrote:
> From 59d128214a62bf2d83c2a2a9cde887b4817275e7 Mon Sep 17 00:00:00 2001
> From: Michal Hocko
> Date: Mon, 26 Aug 2019 12:43:15 +0200
> Subject: [PATCH] mm, memcg
On Tue 27-08-19 19:10:18, Tetsuo Handa wrote:
> On 2019/08/27 16:15, Michal Hocko wrote:
> > All that being said, I do not think this is something we want to merge
> > without a really _strong_ usecase to back it.
>
> Like the sender's domain "arista.com" suggests,
On Tue 27-08-19 11:32:15, Kirill A. Shutemov wrote:
> On Tue, Aug 27, 2019 at 07:59:41AM +0200, Michal Hocko wrote:
> > > > > > IIUC deferred splitting is mostly a workaround for nasty locking
> > > > > > issues
> > > > > > during spli
> With this in mind, since that situation is no longer true, I think we
> could instead drop the NULL check.
This would be much more preferable to the original patch.
--
Michal Hocko
SUSE Labs
On Tue 27-08-19 16:39:56, Alastair D'Silva wrote:
> On Tue, 2019-08-27 at 08:28 +0200, Michal Hocko wrote:
> > On Tue 27-08-19 15:20:46, Alastair D'Silva wrote:
> > > From: Alastair D'Silva
> > >
> > > It is possible for firmware to allocate memory ranges
ernals of subsystems so changes would
have to be carefully considered here as well) without a very strong
demand.
Sure it is a nice to have thing in some cases. I can imagine that some
of that information would have helped me when debugging some weird OOM
reports but I strongly suspect I would likely not have all necessary
pieces enabled because those were not reproducible. Having everything
on is just not usable due to amount of data. printk is not free and
we have seen cases where a lot of output just turned the machine into
unsuable state. If you have a reproducible OOMs then you can trigger
a panic and have the full state of the system to examine. So I am not
really convinced all this is going to be used to justify the maintenance
overhead.
All that being said, I do not think this is something we want to merge
without a really _strong_ usecase to back it.
Thanks!
--
Michal Hocko
SUSE Labs
int rc;
>
> + if ((start + size - 1) >> MAX_PHYSMEM_BITS)
> + return -EINVAL;
> +
> resize_hpt_for_hotplug(memblock_phys_mem_size());
>
> start = (unsigned long)__va(start);
> --
> 2.21.0
--
Michal Hocko
SUSE Labs
On Tue 27-08-19 15:36:54, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> Use the function written to do it instead.
>
> Signed-off-by: Alastair D'Silva
Acked-by: Michal Hocko
> ---
> mm/sparse.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
igned long nr_pages, unsigned long map_offset,
> struct vmem_altmap *altmap)
> {
> - clear_hwpoisoned_pages(pfn_to_page(pfn) + map_offset,
> + clear_hwpoisoned_pages(pfn_to_page(pfn), map_offset,
> nr_pages - map_offset);
> section_deactivate(pfn, nr_pages, altmap);
> }
> --
> 2.21.0
>
--
Michal Hocko
SUSE Labs
On Tue 27-08-19 02:14:20, Bharath Vedartham wrote:
> Hi Michal,
>
> Here are some of my thoughts,
> On Wed, Aug 21, 2019 at 04:06:32PM +0200, Michal Hocko wrote:
> > On Thu 15-08-19 14:51:04, Khalid Aziz wrote:
> > > Hi Michal,
> > >
> > > The sma
On Mon 26-08-19 16:15:38, Kirill A. Shutemov wrote:
> On Mon, Aug 26, 2019 at 09:40:35AM +0200, Michal Hocko wrote:
> > On Thu 22-08-19 18:29:34, Kirill A. Shutemov wrote:
> > > On Thu, Aug 22, 2019 at 02:56:56PM +0200, Vlastimil Babka wrote:
> > > > On 8/22/1
On Mon 26-08-19 21:27:38, Yang Shi wrote:
>
>
> On 8/26/19 12:43 AM, Michal Hocko wrote:
> > On Thu 22-08-19 08:33:40, Yang Shi wrote:
> > >
> > > On 8/22/19 1:04 AM, Michal Hocko wrote:
> > > > On Thu 22-08-19 01:55:25, Yang Shi wrote:
&g
On Mon 26-08-19 22:35:08, Pankaj Suryawanshi wrote:
> On Mon, Aug 26, 2019 at 12:34 PM Michal Hocko wrote:
> >
> > On Thu 22-08-19 23:54:19, Pankaj Suryawanshi wrote:
> > > On Thu, Aug 22, 2019 at 6:22 PM Michal Hocko wrote:
> > > >
> > > > On
ating. Perhaps lockdep experts (not me) would know how to
> express that. If not possible, then replacing GFP_NOFS with __GFP_NOLOCKDEP
> should indeed suppress the warning, while allowing FS reclaim.
This was certainly my hope to happen when introducing __GFP_NOLOCKDEP.
I couldn't have done the second step because that requires a deep
understanding of the code in question which is beyond my capacity. It
seems we still haven't found a brave soul to start converting GFP_NOFS
to __GFP_NOLOCKDEP. And it would be really appreciated.
Thanks.
--
Michal Hocko
SUSE Labs
On Tue 13-08-19 12:51:43, Michal Hocko wrote:
> On Mon 12-08-19 11:07:25, Johannes Weiner wrote:
> > On Mon, Aug 12, 2019 at 10:09:47AM +0200, Michal Hocko wrote:
[...]
> > > > Maybe the refaults will be fine - but latency expectations around
> > > > mapped page
ve it a
serious look. Sorry about that.
> [1]
> https://lore.kernel.org/linux-mm/1541746035-13408-1-git-send-email-n-horigu...@ah.jp.nec.com/
> [2]
> https://lore.kernel.org/linux-mm/1541746035-13408-9-git-send-email-n-horigu...@ah.jp.nec.com/
--
Michal Hocko
SUSE Labs
ck reclaim
state correctly. We just haven't noticed until now beause the warning is
quite recent and mostly likely only few people tend to use soft limit
these days.
That being said, we should simply do this instead:
>From 59d128214a62bf2d83c2a2a9cde887b4817275e7 Mon Sep 17 00:00:00 2001
From: M
On Thu 22-08-19 08:33:40, Yang Shi wrote:
>
>
> On 8/22/19 1:04 AM, Michal Hocko wrote:
> > On Thu 22-08-19 01:55:25, Yang Shi wrote:
[...]
> > > And, they seems very common with the common workloads when THP is
> > > enabled. A simple run with MariaD
On Thu 22-08-19 18:29:34, Kirill A. Shutemov wrote:
> On Thu, Aug 22, 2019 at 02:56:56PM +0200, Vlastimil Babka wrote:
> > On 8/22/19 10:04 AM, Michal Hocko wrote:
> > > On Thu 22-08-19 01:55:25, Yang Shi wrote:
> > >> Available memory is one of the mos
are good to go but I don't think that #3 has
> had suitable review and I have a note here that Michal has concerns
> with it.
My concern was http://lkml.kernel.org/r/20190814113242.gv17...@dhcp22.suse.cz
so more of a code style kinda thing. Roman has chosen to stay with his
original form and added a comment that NR_SLAB_{UN}RECLAIMABLE are
magic. This is something I can live with even though I would have
preferred it a different way. Nothing serious enough to Nack or insist.
--
Michal Hocko
SUSE Labs
On Fri 23-08-19 00:17:22, Pankaj Suryawanshi wrote:
> On Thu, Aug 22, 2019 at 6:32 PM Michal Hocko wrote:
> >
> > On Wed 21-08-19 22:58:03, Pankaj Suryawanshi wrote:
> > > Hello,
> > >
> > > Hard time to understand cma allocation how differs from n
On Thu 22-08-19 23:54:19, Pankaj Suryawanshi wrote:
> On Thu, Aug 22, 2019 at 6:22 PM Michal Hocko wrote:
> >
> > On Wed 21-08-19 22:23:44, Pankaj Suryawanshi wrote:
> > > Hello,
> > >
> > > 1. What are Pageblocks and migrate types(MIGRATE_CMA) in Linu
thing?
> Since the function mem_cgroup_wb_domain() is visible to the global, we
> cannot control caller's behavior.
I am sorry but I do not understand what is this supposed to mean.
--
Michal Hocko
SUSE Labs
us allocator to
get 1GB physically contiguous memory ranges to be used for hugetlb
pages.
HTH
--
Michal Hocko
SUSE Labs
d by default?
There is nothing like that. It depends on how many objects of a specific
type are allocated.
HTH
--
Michal Hocko
SUSE Labs
AnonPages: 1096660 kB
> KReclaimable: 26156 kB
> AnonHugePages: 1056768 kB
>
> After calling madvise(MADV_DONTNEED):
> MemAvailable: 44411164 kB
> AnonPages: 50140 kB
> KReclaimable:1070640 kB
> AnonHugePages: 10240 kB
>
> Suggested-by: Vl
ithtout a larger context - aka other tasks
scores to have something to compare against. Other than that the value
is an internal implementation detail and it is meaningless without
knowing the exact algorithm which can change at any times so no
userspace should really depend on it. All important metrics should be
displayed by the oom report message already.
--
Michal Hocko
SUSE Labs
On Wed 21-08-19 15:22:07, Edward Chron wrote:
> On Wed, Aug 21, 2019 at 12:19 AM David Rientjes wrote:
> >
> > On Wed, 21 Aug 2019, Michal Hocko wrote:
> >
> > > > vm.oom_dump_tasks is pretty useful, however, so it's curious why you
> > > > h
ave a adjustment
> > > of 1000 making it a highly favored OOM kill target process. The output
> > > documents both the misconfiguration and the fact that the process
> > > was correctly targeted by OOM due to the miconfiguration. Having
> > > the oom_score_a
(wb->memcg_css);
>
> - if (!memcg->css.parent)
> + if (!memcg || !memcg->css.parent)
> return NULL;
>
> return >cgwb_domain;
> --
> 2.17.1
>
--
Michal Hocko
SUSE Labs
d. That requires
to identify gaps in that area.
--
Michal Hocko
SUSE Labs
On Wed 21-08-19 00:19:37, David Rientjes wrote:
> On Wed, 21 Aug 2019, Michal Hocko wrote:
>
> > > vm.oom_dump_tasks is pretty useful, however, so it's curious why you
> > > haven't left it enabled :/
> >
> > Because it generates a lot of output potential
that the process
> > was correctly targeted by OOM due to the miconfiguration. Having
> > the oom_score_adj on the Killed message ensures that it is documented.
> >
> > Signed-off-by: Edward Chron
> > Acked-by: Michal Hocko
>
> Acked-by: David Rientjes
>
> vm.oom_du
I believe googlers have tried
something like this in the past but then didn't have really a good
example of workloads that benefit. I might misremember though. Cc Hugh.
--
Michal Hocko
SUSE Labs
gt; vaddr_unpin_user_pages(), once it's ready. (And showing exactly what
> to convert, too.)
If that makes the later conversion easier then no real objections from
me. Assuming that the current put_user_page conversions are correct of
course (I have the mlock one and potentials that falls into the same
category in mind).
--
Michal Hocko
SUSE Labs
On Thu 15-08-19 16:18:10, Jason Gunthorpe wrote:
> On Thu, Aug 15, 2019 at 09:05:25PM +0200, Michal Hocko wrote:
>
> > This is what you claim and I am saying that fs_reclaim is about a
> > restricted reclaim context and it is an ugly hack. It has proven to
> > report false
On Thu 15-08-19 10:27:26, Khalid Aziz wrote:
> On 8/14/19 2:58 AM, Michal Hocko wrote:
> > On Tue 13-08-19 09:20:51, Khalid Aziz wrote:
> >> On 8/13/19 8:05 AM, Michal Hocko wrote:
> >>> On Mon 12-08-19 19:40:10, Khalid Aziz wrote:
> >>> [...]
>
On Wed 14-08-19 21:51:47, Yang Shi wrote:
>
>
> On 8/14/19 4:08 AM, Michal Hocko wrote:
> > On Mon 12-08-19 10:00:17, Yang Shi wrote:
> > >
> > > On 8/12/19 2:34 AM, Michal Hocko wrote:
> > > > On Fri 09-08-19 16:54:43, Yang Shi wrote:
On Wed 14-08-19 21:54:12, Roman Gushchin wrote:
> On Wed, Aug 14, 2019 at 01:32:42PM +0200, Michal Hocko wrote:
> > On Mon 12-08-19 15:29:11, Roman Gushchin wrote:
> > > I've noticed that the "slab" value in memory.stat is sometimes 0,
> > > even if some ch
t; Aug 14 23:00:02 testserver kernel: Out of memory: Killed process 2692
> (oomprocs) total-vm:1056800kB, anon-rss:1052760kB, file-rss:4kB,i
> shmem-rss:0kB oom_score_adj:1000
>
> Signed-off-by: Edward Chron
With that feel free to add
Acked-by: Michal Hocko
and post as a stand alo
On Wed 14-08-19 23:24:51, Edward Chron wrote:
> On Mon, Aug 12, 2019 at 4:42 AM Michal Hocko wrote:
> >
> > On Fri 09-08-19 15:15:18, Edward Chron wrote:
> > [...]
> > > So it is optimal if you only have to go and find the correct log and
> > > sear
On Wed 14-08-19 12:32:03, Joel Fernandes wrote:
> On Wed, Aug 14, 2019 at 10:05:31AM +0200, Michal Hocko wrote:
> > On Tue 13-08-19 11:36:59, Joel Fernandes wrote:
> > > On Tue, Aug 13, 2019 at 05:04:50PM +0200, Michal Hocko wrote:
> > > > On Wed 07-08-19 13:15:55,
X_ORDER - 1, I am not convinced that is always true. Let's play safe,
> > check the alignment and fallback to single pages.
> >
> > Cc: Arun KS
> > Cc: Andrew Morton
> > Cc: Oscar Salvador
> > Cc: Michal Hocko
> > Cc: Pavel Tatashin
> > Cc: Dan Willi
On Wed 14-08-19 17:41:07, David Hildenbrand wrote:
> online_pages always corresponds to nr_pages. Simplify the code, getting
> rid of online_pages_blocks(). Add some comments.
>
> Cc: Andrew Morton
> Cc: Oscar Salvador
> Cc: Michal Hocko
> Cc: Pavel Tatashin
> Cc: Da
adding memory and we wanted to check for already
> onlined memory.
>
> Cc: Andrew Morton
> Cc: Oscar Salvador
> Cc: Michal Hocko
> Cc: Pavel Tatashin
> Cc: Dan Williams
> Signed-off-by: David Hildenbrand
Thanks for spliting that up.
Acked-by: Michal Hocko
> ---
> mm
On Wed 14-08-19 16:28:21, David Hildenbrand wrote:
> On 14.08.19 16:17, David Hildenbrand wrote:
> > On 14.08.19 16:08, Michal Hocko wrote:
> >> On Fri 09-08-19 14:56:59, David Hildenbrand wrote:
> >>> Take care of nr_pages not being a power of two and start no
On Wed 14-08-19 16:17:03, David Hildenbrand wrote:
> On 14.08.19 16:08, Michal Hocko wrote:
> > On Fri 09-08-19 14:56:59, David Hildenbrand wrote:
> >> Take care of nr_pages not being a power of two and start not being
> >> properly aligned. Essentially, what walk_syste
ve online_pages > 0.
I have no idea why those checks where there TBH. Tried to dig out
commits which added them but didn't help.
> Remove that special handling.
>
> Cc: Andrew Morton
> Cc: Oscar Salvador
> Cc: Michal Hocko
> Cc: Pavel Tatashin
> Cc: Dan Williams
>
em is even real then it
can be done on top instead with some real example of the memory layout
that breaks.
> Cc: Andrew Morton
> Cc: Oscar Salvador
> Cc: Michal Hocko
> Cc: Pavel Tatashin
> Cc: Dan Williams
> Signed-off-by: David H
d29 ("mm/page_alloc.c: memory hotplug: free pages as higher
> order")
> Cc: Arun KS
> Cc: Andrew Morton
> Cc: Oscar Salvador
> Cc: Michal Hocko
> Cc: Pavel Tatashin
> Cc: Dan Williams
> Signed-off-by: David Hildenbrand
> ---
> mm/memory_hotplug.c | 4
tkov
> Cc: Andrew Morton
> Cc: Bjorn Helgaas
> Cc: Ingo Molnar
> Cc: Dave Hansen
> Cc: Nadav Amit
> Cc: Wei Yang
> Cc: Oscar Salvador
> Signed-off-by: David Hildenbrand
Acked-by: Michal Hocko
> ---
> kernel/resource.c | 4 ++--
> 1 file changed, 2 ins
e they are
> unmapped, they are in fact kernel-only, so IMHO it wouldn't be a big stretch
> to
> add the lazy THP pages there?
That would indeed fit in much better than a dedicated counter.
--
Michal Hocko
SUSE Labs
ush percpu vmstats anyway, we can
> iterate only over online cpus.
>
> Fixes: 42a300353577 ("mm: memcontrol: fix recursive statistics correctness &
> scalabilty")
> Signed-off-by: Roman Gushchin
> Cc: Johannes Weiner
Acked-by: Michal Hocko
> ---
> mm/memcontr
r counter flush and do
the loop over all counters resp. specific counters around it so much
worse? This should be really a slow path to safe few instructions or
cache misses, no?
--
Michal Hocko
SUSE Labs
stats anyway, we can
> iterate only over online cpus.
>
> Fixes: 42a300353577 ("mm: memcontrol: fix recursive statistics correctness &
> scalabilty")
> Signed-off-by: Roman Gushchin
> Cc: Johannes Weiner
Acked-by: Michal Hocko
> ---
> mm/memcontrol.c | 40
On Mon 12-08-19 10:00:17, Yang Shi wrote:
>
>
> On 8/12/19 2:34 AM, Michal Hocko wrote:
> > On Fri 09-08-19 16:54:43, Yang Shi wrote:
> > >
> > > On 8/9/19 11:26 AM, Yang Shi wrote:
> > > >
> > > > On 8/9/19 11:02 AM, Michal Hocko wrot
On Tue 13-08-19 09:20:51, Khalid Aziz wrote:
> On 8/13/19 8:05 AM, Michal Hocko wrote:
> > On Mon 12-08-19 19:40:10, Khalid Aziz wrote:
> > [...]
> >> Patch 1 adds code to maintain a sliding lookback window of (time, number
> >> of free pages) points which can be u
On Tue 13-08-19 13:12:37, Johannes Weiner wrote:
> On Tue, Aug 13, 2019 at 03:29:38PM +0200, Michal Hocko wrote:
> > On Mon 12-08-19 15:23:16, Johannes Weiner wrote:
[...]
> > > This change completely eliminates the OOM kills on our service, while
> > > show
int of this background reclaim is to
keep balance and prevent from direct reclaim. Why cannot you implement
this or any other dynamic trend watching watchdog and tune watermarks
accordingly? Something similar applies to kcompactd although we might be
lacking a good interface.
--
Michal Hocko
SUSE Labs
rect charges which makes some
reclaimers hit memcgs without pages more likely.
Let's see whether we see regression due to over-reclaim.
> Signed-off-by: Johannes Weiner
With the direct reclaim bail out reference fixed - unless I am wrong
there of course
Acked-by: Michal Hocko
It is sad
On Mon 12-08-19 11:07:25, Johannes Weiner wrote:
> On Mon, Aug 12, 2019 at 10:09:47AM +0200, Michal Hocko wrote:
[...]
> > Btw. can we promote PageReferenced pages with zero mapcount? I am
> > throwing that more as an idea because I haven't really thought that
> > throug
o some state.
Ideal? Not at all and I am happy to hear some better ideas. Until then
we simply have to rely on gut feeling and understanding of the code
and experience from workloads we have seen in the past.
--
Michal Hocko
SUSE Labs
unexpected...
> NOTE: This is not tested since I didn't manage to create a case to
> offline a whole node. If my analysis is not correct, please let me know.
>
> Signed-off-by: Wei Yang
Acked-by: Michal Hocko
Thanks!
> ---
> mm/memory_hotplug.c | 10 +-
> 1 file changed, 9 in
On Mon 12-08-19 15:14:12, Vlastimil Babka wrote:
> On 8/12/19 10:45 AM, Michal Hocko wrote:
> > On Sun 11-08-19 19:46:14, Sasha Levin wrote:
> >> On Fri, Aug 09, 2019 at 03:17:18PM -0700, Andrew Morton wrote:
> >>> On Fri, 9 Aug 2019 08:46:33 +0200 Michal Hocko wro
ed and should be included.
I am willing to ack a patch to add oom_score_adj on the grounds that
this information is helpful to pinpoint misconfigurations and it is not
generally available when dump_tasks is disabled.
> In Summary:
>
> I hope I have presented a reasonable enough argument for the proposed
> additional parameters.
I am not convinced on oom_score and percentage part because score on its
own is an implementation detail that makes sense when comparing tasks
but on on its own and percentage might be even confusing as explained
above.
Thanks for your detailed information!
--
Michal Hocko
SUSE Labs
On Fri 09-08-19 16:54:43, Yang Shi wrote:
>
>
> On 8/9/19 11:26 AM, Yang Shi wrote:
> >
> >
> > On 8/9/19 11:02 AM, Michal Hocko wrote:
[...]
> > > I have to study the code some more but is there any reason why those
> > > pages are not accounted as
On Sun 11-08-19 19:46:14, Sasha Levin wrote:
> On Fri, Aug 09, 2019 at 03:17:18PM -0700, Andrew Morton wrote:
> > On Fri, 9 Aug 2019 08:46:33 +0200 Michal Hocko wrote:
> >
> > > > Maybe we should introduce the Fixes-no-stable: tag. That should get
> > > >
On Sat 10-08-19 13:34:06, ndrw wrote:
> On 09/08/2019 11:50, Michal Hocko wrote:
> > We try to protect low amount of cache. Have a look at get_scan_count
> > function. But the exact amount of the cache to be protected is really
> > hard to know wihtout a crystal
On Fri 09-08-19 14:34:24, Johannes Weiner wrote:
> On Fri, Aug 09, 2019 at 02:43:24PM +0200, Michal Hocko wrote:
> > On Tue 06-08-19 19:55:09, Minchan Kim wrote:
> > > On Wed, Jul 31, 2019 at 09:21:01AM +0200, Michal Hocko wrote:
> > > > On Wed 31-07-
On Fri 09-08-19 09:19:13, Yang Shi wrote:
>
>
> On 8/9/19 1:32 AM, Michal Hocko wrote:
> > On Fri 09-08-19 07:57:44, Yang Shi wrote:
> > > When doing partial unmap to THP, the pages in the affected range would
> > > be considered to be recla
On Fri 09-08-19 15:58:13, Jan Kara wrote:
> On Fri 09-08-19 10:23:07, Michal Hocko wrote:
> > On Fri 09-08-19 10:12:48, Vlastimil Babka wrote:
> > > On 8/9/19 12:59 AM, John Hubbard wrote:
> > > >>> That's true. However, I'm not sure munlocking is where the
On Tue 06-08-19 19:55:09, Minchan Kim wrote:
> On Wed, Jul 31, 2019 at 09:21:01AM +0200, Michal Hocko wrote:
> > On Wed 31-07-19 14:44:47, Minchan Kim wrote:
[...]
> > > As Nick mentioned in the description, without mark_page_accessed in
> > > zapping part, repeated
On Fri 09-08-19 11:09:33, ndrw wrote:
> On 09/08/2019 09:57, Michal Hocko wrote:
> > We already do have a reserve (min_free_kbytes). That gives kswapd some
> > room to perform reclaim in the background without obvious latencies to
> > allocating tasks (well CPU still be used s
On Fri 09-08-19 02:05:15, John Hubbard wrote:
> On 8/9/19 1:23 AM, Michal Hocko wrote:
> > On Fri 09-08-19 10:12:48, Vlastimil Babka wrote:
> > > On 8/9/19 12:59 AM, John Hubbard wrote:
> > > > > > That's true. However, I'm not sure munlocking is where the
&
On Thu 08-08-19 22:59:32, ndrw wrote:
> On 08/08/2019 19:59, Michal Hocko wrote:
> > Well, I am afraid that implementing anything like that in the kernel
> > will lead to many regressions and bug reports. People tend to have very
> > different opinions on when it is suitable
er memory pressure (i.e. deferred
> + split THP).
What does that mean actually? I have hard time imagine what cleanly
freeable pages mean.
--
Michal Hocko
SUSE Labs
o use?
Agreed. This is a shiny example how forcing all existing gup users into
the new scheme is subotimal at best. Not the mention the overal
fragility mention elsewhere. I dislike the conversion even more now.
Sorry if this was already discussed already but why the new pinning is
not bound to FOLL_LONGTERM (ideally hidden by an interface so that users
do not have to care about the flag) only?
--
Michal Hocko
SUSE Labs
On Thu 08-08-19 16:39:28, Andrew Morton wrote:
> On Thu, 8 Aug 2019 20:53:13 +0200 Michal Hocko wrote:
>
> > > https://lkml.org/lkml/2019/6/1/165
> > >
> > > Ironic to find that commit message in a stable backport.
> > >
> > > I'm happy to
hough. Seeing biased -
one way or the other - tasks being selected might confirm the setting is
reasonable or otherwise (e.g. seeing tasks with negative scores will
give an indication that they might be not biased enough). Then you can
go and check the eligible tasks dump and see what happened. So this part
makes some sense to me.
--
Michal Hocko
SUSE Labs
uch
memory will get freed when the victim dies - rss is a very rough
estimation. But is a portion of the overal memory or oom_score{_adj}
important to print as well? Those are relative values. Say you get
memory-usage:10%, oom_score:42 and oom_score_adj:0. What are you going
to tell from that information?
--
Michal Hocko
SUSE Labs
On Thu 08-08-19 18:57:02, ndrw...@redhazel.co.uk wrote:
>
>
> On 8 August 2019 17:32:28 BST, Michal Hocko wrote:
> >
> >> Would it be possible to reserve a fixed (configurable) amount of RAM
> >for caches,
> >
> >I am afraid there is nothing
On Thu 08-08-19 09:55:45, Mike Kravetz wrote:
> On 8/8/19 12:47 AM, Michal Hocko wrote:
> > On Thu 08-08-19 09:46:07, Michal Hocko wrote:
> >> On Wed 07-08-19 17:05:33, Mike Kravetz wrote:
> >>> Li Wang discovered that LTP/move_page12 V2 sometimes triggers SIGBUS
>
ges to be printed as
well? How is that information useful?
--
Michal Hocko
SUSE Labs
On Thu 08-08-19 16:10:07, ndrw...@redhazel.co.uk wrote:
>
>
> On 8 August 2019 12:48:26 BST, Michal Hocko wrote:
> >>
> >> Per default, the OOM killer will engage after 15 seconds of at least
> >> 80% memory pressure. These values are tunable via
vain" problem inside the reclaim path but I do not think this
will ever work and having a watchdog like this sound like step in the
right direction. I didn't even expect it would look as simple. Really a
nice work Johannes!
Let's see how this ends up working in practice though.
Acked-by: Michal
1701 - 1800 of 20557 matches
Mail list logo
