y the Linux
> +kernel team.
Does the process focus only on assigning CVE numbers to a given upstream
commit(s) withou any specifics of the actual security threat covered by
the said CVE?
--
Michal Hocko
SUSE Labs
On Thu 15-02-24 19:20:09, Greg KH wrote:
> On Thu, Feb 15, 2024 at 06:54:17PM +0100, Michal Hocko wrote:
> > On Wed 14-02-24 09:00:30, Greg KH wrote:
> > [...]
> > > +Process
> > > +---
> > > +
> > > +As part of the normal stable release
On Fri 16-02-24 12:25:46, Greg KH wrote:
> On Thu, Feb 15, 2024 at 07:36:20PM +0100, Michal Hocko wrote:
> > On Thu 15-02-24 19:20:09, Greg KH wrote:
> > > On Thu, Feb 15, 2024 at 06:54:17PM +0100, Michal Hocko wrote:
> > > > On Wed 14
On Fri 16-02-24 16:34:57, Greg KH wrote:
> On Fri, Feb 16, 2024 at 02:20:04PM +0100, Michal Hocko wrote:
> > > Right now
> > > we are fixing lots and lots of things and no one notices as their
> > > "traditional" path of only looking at CVEs f
process.
I do not think you can make any argument about accuracy because
the information will never be accurate. Sure the race window is smaller
in principle but you can hardly say anything about how much or whether
at all.
Thanks.
--
Michal Hocko
SUSE Labs
le(pte_t pte)
> +{
> + return set_pte_bit(pte, __pgprot(PTE_SWP_PGIDLE));
> +}
> +
> +static inline pte_t pte_swp_clear_page_idle(pte_t pte)
> +{
> + return clear_pte_bit(pte, __pgprot(PTE_SWP_PGIDLE));
> +}
> +
> static inline void set_pte(pte_t *ptep, pte_t pte)
> {
> WRITE_ONCE(*ptep, pte);
> --
> 2.22.0.770.g0f2c4a37fd-goog
--
Michal Hocko
SUSE Labs
ze_t page_idle_proc_generic(struct file *file, char
> __user *ubuff,
> walk.private = &priv;
> walk.mm = mm;
>
> + lru_add_drain_all();
> +
> down_read(&mm->mmap_sem);
>
> /*
> --
> 2.22.0.770.g0f2c4a37fd-goog
--
Michal Hocko
SUSE Labs
will try to go through the patch more carefully later as time allows.
> Signed-off-by: Joel Fernandes (Google)
--
Michal Hocko
SUSE Labs
On Tue 06-08-19 06:36:27, Joel Fernandes wrote:
> On Tue, Aug 06, 2019 at 10:42:03AM +0200, Michal Hocko wrote:
> > On Mon 05-08-19 13:04:49, Joel Fernandes (Google) wrote:
> > > This bit will be used by idle page tracking code to correctly identify
> > > if a page th
On Tue 06-08-19 06:45:54, Joel Fernandes wrote:
> On Tue, Aug 06, 2019 at 10:43:57AM +0200, Michal Hocko wrote:
> > On Mon 05-08-19 13:04:50, Joel Fernandes (Google) wrote:
> > > During idle tracking, we see that sometimes faulted anon pages are in
> > > pagevec but a
On Tue 06-08-19 20:07:37, Minchan Kim wrote:
> On Tue, Aug 06, 2019 at 12:47:55PM +0200, Michal Hocko wrote:
> > On Tue 06-08-19 06:36:27, Joel Fernandes wrote:
> > > On Tue, Aug 06, 2019 at 10:42:03AM +0200, Michal Hocko wrote:
> > > > On Mon 05-08-19 13:04:49,
On Tue 06-08-19 07:19:21, Joel Fernandes wrote:
> On Tue, Aug 06, 2019 at 12:51:49PM +0200, Michal Hocko wrote:
> > On Tue 06-08-19 06:45:54, Joel Fernandes wrote:
> > > On Tue, Aug 06, 2019 at 10:43:57AM +0200, Michal Hocko wrote:
> > > > On Mon 05-08-19 13:04:50,
On Tue 06-08-19 07:14:46, Joel Fernandes wrote:
> On Tue, Aug 06, 2019 at 12:47:55PM +0200, Michal Hocko wrote:
> > On Tue 06-08-19 06:36:27, Joel Fernandes wrote:
> > > On Tue, Aug 06, 2019 at 10:42:03AM +0200, Michal Hocko wrote:
> > > > On Mon 05-08-19 13:04:49,
On Tue 06-08-19 09:43:21, Joel Fernandes wrote:
> On Tue, Aug 06, 2019 at 01:57:03PM +0200, Michal Hocko wrote:
> > On Tue 06-08-19 07:14:46, Joel Fernandes wrote:
> > > On Tue, Aug 06, 2019 at 12:47:55PM +0200, Michal Hocko wrote:
> > > > On Tue 06-08-19
ew interface being added is what
> will be used more than the old interface (for some of the usecases) so it
> makes sense to keep it alive with CONFIG_IDLE_PAGE_TRACKING.
I would tend to agree with Joel here. The functionality falls into an
existing IDLE_PAGE_TRACKING config option quite nicely. If there really
are users who want to save some space and this is standing in the way
then they can easily add a new config option with some justification so
the savings are clear. Without that an additional config simply adds to
the already existing configurability complexity and balkanization.
--
Michal Hocko
SUSE Labs
On Mon 12-08-19 10:56:20, Joel Fernandes wrote:
> On Thu, Aug 08, 2019 at 10:00:44AM +0200, Michal Hocko wrote:
> > On Wed 07-08-19 17:31:05, Joel Fernandes wrote:
> > > On Wed, Aug 07, 2019 at 01:58:40PM -0700, Andrew Morton wrote:
> > > > On Wed, 7 Aug 2019
thout that you
cannot get to any page so the new interface is weakening the rules.
Maybe we should limit setting the idle state to processes with the write
status. Or do you think that even observing idle status is useful for
practical side channel attacks? If yes, is that a problem of the
profiler which does potentially dangerous things?
--
Michal Hocko
SUSE Labs
On Tue 13-08-19 09:51:52, Joel Fernandes wrote:
> On Tue, Aug 13, 2019 at 11:14:30AM +0200, Michal Hocko wrote:
> > On Mon 12-08-19 10:56:20, Joel Fernandes wrote:
> > > On Thu, Aug 08, 2019 at 10:00:44AM +0200, Michal Hocko wrote:
> > > > On Wed 07-08-19
On Tue 13-08-19 10:45:17, Joel Fernandes wrote:
> On Tue, Aug 13, 2019 at 04:14:32PM +0200, Michal Hocko wrote:
> [snip]
> > > > If the API is flawed then this is likely going
> > > > to kick us later and will be hard to fix. I am still not convinced about
> >
uess for
tracking. If that is fundamentally not possible then please describe
why.
--
Michal Hocko
SUSE Labs
On Tue 13-08-19 17:29:09, Jann Horn wrote:
> On Tue, Aug 13, 2019 at 12:09 PM Michal Hocko wrote:
> > On Mon 12-08-19 20:14:38, Jann Horn wrote:
> > > On Wed, Aug 7, 2019 at 7:16 PM Joel Fernandes (Google)
> > > wrote:
> > > > The page_idle tracking fe
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, Joel Fernandes (Google) wrote:
> > > Idle page tracking currently does not work well in the following
> > > scenario:
> >
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,
ack)(struct mem_cgroup *memcg, void *arg),
> +void *arg)
> +{
> + struct mem_cgroup *memcg;
> +
> + for_each_mem_cgroup(memcg)
> + callback(memcg, arg);
> +}
> +
> /**
> * mem_cgroup_css_from_page - css of the memcg associated with a page
> * @page: page of interest
> --
> 2.18.1
--
Michal Hocko
SUSE Labs
ut cache effects - from using
this interface and therefore I am not really happy to paper over
something that might be a real problem with yet another mode. If SLUB
indeed caches too aggressively on large machines then this should be
fixed.
--
Michal Hocko
SUSE Labs
On Thu 27-06-19 17:03:06, Waiman Long wrote:
> On 6/27/19 11:07 AM, Michal Hocko wrote:
> > On Mon 24-06-19 13:42:18, Waiman Long wrote:
> >> Add a memcg_iterate_all() function for iterating all the available
> >> memory cgroups and call the given callback function
On Thu 27-06-19 17:16:04, Waiman Long wrote:
> On 6/27/19 11:15 AM, Michal Hocko wrote:
> > On Mon 24-06-19 13:42:19, Waiman Long wrote:
> >> With the slub memory allocator, the numbers of active slab objects
> >> reported in /proc/slabinfo are not real because they in
ate decision to cover root caches only?
--
Michal Hocko
SUSE Labs
On Wed 03-07-19 09:12:13, Waiman Long wrote:
> On 7/3/19 2:56 AM, Michal Hocko wrote:
> > On Tue 02-07-19 14:37:30, Waiman Long wrote:
> >> Currently, a value of '1" is written to /sys/kernel/slab//shrink
> >> file to shrink the slab by flushing all the per-cpu
act. People just
got used to drop caches because they were told so by $random web page.
So really, think about the underlying problem and try to fix it.
It is true that you could argue that this patch is actually fixing the
existing interface because it doesn't really do what it is documented to
do and on those grounds I would agree with the change. But do not teach
people that they have to write to some file to get proper numbers.
Because that is just a bad idea and it will kick back the same way
drop_caches.
--
Michal Hocko
SUSE Labs
On Wed 03-07-19 12:16:09, Waiman Long wrote:
> On 7/3/19 11:53 AM, Michal Hocko wrote:
> > On Wed 03-07-19 11:21:16, Waiman Long wrote:
> >> On 7/2/19 5:33 PM, Andrew Morton wrote:
> >>> On Tue, 2 Jul 2019 16:44:24 -0400 Waiman Long wrote:
> >>>
>
ngset_nodereclaim.
>
> This commit adds a corresponding description to the cgroup v2 docs.
>
> Signed-off-by: Roman Gushchin
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Vladimir Davydov
> Cc: Tejun Heo
> Cc: Li Zefan
> Cc: cgro...@vger.kernel.org
> Cc:
using /proc/vmstat.
>
> Also, for consistency, rename mem_cgroup_count_vm_event() to
> count_memcg_event_mm().
>
> Signed-off-by: Roman Gushchin
> Suggested-by: Johannes Weiner
> Cc: Johannes Weiner
> Cc: Tejun Heo
> Cc: Li Zefan
> Cc: Michal Hocko
> Cc: V
that. One possibility was to allow bpf like
mechanisms. Could you explore that path?
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu 18-05-17 14:11:17, Johannes Weiner wrote:
> On Thu, May 18, 2017 at 07:30:04PM +0200, Michal Hocko wrote:
> > On Thu 18-05-17 17:28:04, Roman Gushchin wrote:
> > > Traditionally, the OOM killer is operating on a process level.
> > > Under oom conditions, it finds
Weiner
> Cc: Tejun Heo
> Cc: Li Zefan
> Cc: Michal Hocko
> Cc: Vladimir Davydov
> Cc: cgro...@vger.kernel.org
> Cc: linux-doc@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux...@kvack.org
Acked-by: Michal Hocko
Thanks!
> ---
> Documentation/cgroup
ompare processes with cgroups.
> I agree, that we can have some option to disable the cgroup-aware OOM at all,
> mostly for backward-compatibility. But I don't think it should be a
> per-cgroup configuration option, which we will support forever.
I can clearly see a demand for "thi
On Tue 23-05-17 09:25:44, Johannes Weiner wrote:
> On Tue, May 23, 2017 at 09:07:47AM +0200, Michal Hocko wrote:
> > On Mon 22-05-17 18:01:16, Roman Gushchin wrote:
[...]
> > > How to react on an OOM - is definitely a policy, which depends
> > > on the workload. Nothin
[I am sorry I didn't get to reply earlier]
On Thu 25-05-17 13:08:05, Johannes Weiner wrote:
> On Thu, May 25, 2017 at 05:38:19PM +0200, Michal Hocko wrote:
> > On Tue 23-05-17 09:25:44, Johannes Weiner wrote:
[...]
> > > We don't need any elaborate
> > >
On Wed 31-05-17 14:01:45, Johannes Weiner wrote:
> On Wed, May 31, 2017 at 06:25:04PM +0200, Michal Hocko wrote:
> > On Thu 25-05-17 13:08:05, Johannes Weiner wrote:
> > > Everything the user would want to dynamically program in the kernel,
> > > say with bpf, they cou
On Fri 02-06-17 16:18:52, Roman Gushchin wrote:
> On Fri, Jun 02, 2017 at 10:43:33AM +0200, Michal Hocko wrote:
> > On Wed 31-05-17 14:01:45, Johannes Weiner wrote:
> > > On Wed, May 31, 2017 at 06:25:04PM +0200, Michal Hocko wrote:
> > > > > > + /*
> &g
ERGE_DEFAULT);
>
> static int __init setup_slab_nomerge(char *str)
> {
> - slab_nomerge = 1;
> + slab_nomerge = true;
> return 1;
> }
>
> --
> 2.7.4
>
>
> --
> Kees Cook
> Pixel Security
>
> --
> To unsubscribe, send a message wi
On Fri 23-06-17 12:20:25, Kees Cook wrote:
> On Fri, Jun 23, 2017 at 7:06 AM, Michal Hocko wrote:
> > On Tue 20-06-17 16:09:11, Kees Cook wrote:
> >> Some hardened environments want to build kernels with slab_nomerge
> >> already set (so that they do not depend on re
y reason to go the reduced
memory reserves access to oom victims I was suggesting earlier [1]?
[1]
http://lkml.kernel.org/r/http://lkml.kernel.org/r/1472723464-22866-2-git-send-email-mho...@kernel.org
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscrib
memcg in the oom hierarchy with oom victims which are alive
and not MMF_OOM_SKIP, you should abort the scanning.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu 29-06-17 14:45:13, Roman Gushchin wrote:
> On Thu, Jun 29, 2017 at 10:53:57AM +0200, Michal Hocko wrote:
> > On Wed 21-06-17 22:19:15, Roman Gushchin wrote:
> > > We want to limit the number of tasks which are having an access
> > > to the memory reserves. To ensu
do
you need to store anything in the pte? My understanding of PKEYs is that
the setup and teardown should be very cheap and so no page tables have
to updated. Or do I just misunderstand what you wrote here?
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe
On Tue 11-07-17 12:32:57, Ram Pai wrote:
> On Tue, Jul 11, 2017 at 04:52:46PM +0200, Michal Hocko wrote:
> > On Wed 05-07-17 14:21:37, Ram Pai wrote:
> > > Memory protection keys enable applications to protect its
> > > address space from inadvertent access or c
On Wed 12-07-17 09:23:37, Michal Hocko wrote:
> On Tue 11-07-17 12:32:57, Ram Pai wrote:
[...]
> > Ideally the MMU looks at the PTE for keys, in order to enforce
> > protection. This is the case with x86 and is the case with power9 Radix
> > page table. Hence the keys have
On Thu 13-07-17 08:53:52, Benjamin Herrenschmidt wrote:
> On Wed, 2017-07-12 at 09:23 +0200, Michal Hocko wrote:
> >
> > >
> > > Ideally the MMU looks at the PTE for keys, in order to enforce
> > > protection. This is the case with x86 and is the case with
spin_lock_irqsave(&zone->lock, flags);
> tmp = (u64)pages_min * zone->managed_pages;
> @@ -7026,7 +7028,9 @@ static void __setup_per_zone_wmarks(void)
> watermark_scale_factor, 1));
>
> zone->wat
On Fri 24-11-17 14:12:56, peter enderborg wrote:
> On 11/24/2017 11:14 AM, Michal Hocko wrote:
> > On Fri 24-11-17 11:07:07, Peter Enderborg wrote:
> >> When tuning the watermark_scale_factor to reduce stalls and compactions
> >> the high mark is also changed, it chan
implementation a special approximation
> is used for estimating oom_score of root memory cgroup: we sum
> oom_score of the belonging processes (or, to be more precise,
> tasks owning their mm structures).
>
> Signed-off-by: Roman Gushchin
> Cc: Michal Hocko
> Cc: Johannes We
mounting the cgroupfs.
Is it ok to create oom_group if the option is not enabled? This looks
confusing. I forgot all the details about how cgroup core creates file
so I do not have a good idea how to fix this.
> Signed-off-by: Roman Gushchin
> Cc: Michal Hocko
> Cc: Vladimir Davydov
>
.
>
> +OOM Killer
> +~~
> +
> +Cgroup v2 memory controller implements a cgroup-aware OOM killer.
> +It means that it treats cgroups as first class OOM entities.
This should mention groupoom mount option to enable this functionality.
Other than that looks ok to me
Acked-by:
Recently added alloc_pages_before_oomkill gained new caller with this
patchset and I think it just grown to deserve a simpler code flow.
What do you think about this on top of the series?
---
>From f1f6035ea0df65e7619860b013f2fabdda65233e Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Fri
On Fri 01-12-17 13:15:38, Roman Gushchin wrote:
[...]
> So, maybe we just need to return -EAGAIN (or may be -ENOTSUP) on any
> read/write
> attempt if option is not enabled?
Yes, that would work as well. ENOTSUP sounds better to me.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from
On Fri 01-12-17 13:32:15, Roman Gushchin wrote:
> Hi, Michal!
>
> I totally agree that out_of_memory() function deserves some refactoring.
>
> But I think there is an issue with your patch (see below):
>
> On Fri, Dec 01, 2017 at 10:14:25AM +0100, Michal Hocko wrot
controller tries to make the best
> choice of a victim, looking for a memory cgroup with the largest
> memory footprint, considering leaf cgroups and cgroups with the
Looks good to me
Thanks!
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscri
to go with
the current scheme for some good reasons. There are cons/pros for both
approaches but I am not convinced we should convolute the user API for
the usecase you describe.
> Signed-off-by: Shakeel Butt
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
t; That requires that the heuristic uses hierarchical usage rather than
> > > considering each cgroup as independent consumers as it does today. We
> > > need to implement that heuristic and introduce userspace influence over
> > > oom kill selection now rather than la
of your email because it is _yet_
_again_ a form of obstructing the current patchset which is what you
have been doing for quite some time. I will leave the final decision
for merging to Andrew. If you want to build a more fine grained control
on top, you are free to do so. I will be reviewing those
On Tue 16-01-18 13:36:21, David Rientjes wrote:
> On Mon, 15 Jan 2018, Michal Hocko wrote:
>
> > > No, this isn't how kernel features get introduced. We don't design a new
> > > kernel feature with its own API for a highly specialized usecase and then
> &
ing by conflating selection and the
action is a no go and a wrong API. This is why I've said that what you
(David) outlined yesterday is probably going to suffer from a much
longer discussion and most likely to be not acceptable. Your patchset
proves me correct...
--
Michal Hocko
SUSE Labs
--
T
On Wed 17-01-18 14:18:33, David Rientjes wrote:
> On Wed, 17 Jan 2018, Michal Hocko wrote:
>
> > Absolutely agreed! And moreover, there are not all that many ways what
> > to do as an action. You just kill a logical entity - be it a process or
> > a logical group of pro
l be always a subject to changes in future. Current
implementation doesn't provide any externally controlable selection
policy and therefore the default can be assumed. Whatever that default
means now or in future. The only contract added here is the kill full
memcg if selected and that can be imple
On Tue 23-01-18 14:22:07, David Rientjes wrote:
> On Tue, 23 Jan 2018, Michal Hocko wrote:
>
> > > It can't, because the current patchset locks the system into a single
> > > selection criteria that is unnecessary and the mount option would become
> > &g
On Wed 24-01-18 13:44:02, David Rientjes wrote:
> On Wed, 24 Jan 2018, Michal Hocko wrote:
>
> > > The current implementation of memory.oom_group is based on top of a
> > > selection implementation that is broken in three ways I have listed for
> > > mont
not an API hazard AFAICS.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu 25-01-18 15:27:29, David Rientjes wrote:
> On Thu, 25 Jan 2018, Michal Hocko wrote:
>
> > > As a result, this would remove patch 3/4 from the series. Do you have
> > > any
> > > other feedback regarding the remainder of this patch series before I
>
tencies there as well.
I am not sure how extensible this is actually. How do we place
priorities on top?
> Signed-off-by: David Rientjes
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
hes are nice. We can cc:stable them too, so no huge
> hurry.
What about this?
>From c02d8bc1396d5ab3785d01f577e2ee74e5dd985e Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Mon, 29 Jan 2018 11:42:59 +0100
Subject: [PATCH] oom, memcg: clarify root memcg oom accounting
David Rientjes has pointed
On Mon 29-01-18 14:38:02, David Rientjes wrote:
> On Fri, 26 Jan 2018, Michal Hocko wrote:
>
> > > The cgroup aware oom killer is needlessly declared for the entire system
> > > by a mount option. It's unnecessary to force the system into a single
> > > o
On Mon 29-01-18 11:11:39, Tejun Heo wrote:
> Hello, Michal.
>
> On Mon, Jan 29, 2018 at 11:46:57AM +0100, Michal Hocko wrote:
> > @@ -1292,7 +1292,11 @@ the memory controller considers only cgroups
> > belonging to the sub-tree
> > of the OOM'ing cgroup.
> >
On Tue 30-01-18 11:58:51, Roman Gushchin wrote:
> On Tue, Jan 30, 2018 at 09:54:45AM +0100, Michal Hocko wrote:
> > On Mon 29-01-18 11:11:39, Tejun Heo wrote:
>
> Hello, Michal!
>
> > diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
> > in
re? The previous patch should make
arch_pkeys_enabled == F when CONFIG_ARCH_HAS_PKEYS=n. Btw. could you
merge those two patches into one. It is usually much easier to review a
new helper function if it is added along with a user.
> m_cache_vma(m, vma);
> return ret;
> }
> --
On Tue 30-01-18 12:13:22, Roman Gushchin wrote:
> On Tue, Jan 30, 2018 at 01:08:52PM +0100, Michal Hocko wrote:
> > On Tue 30-01-18 11:58:51, Roman Gushchin wrote:
> > > On Tue, Jan 30, 2018 at 09:54:45AM +0100, Michal Hocko wrote:
> > > > On Mon 29-0
On Tue 30-01-18 17:42:13, Florian Schmidt wrote:
> There is no entry file_mapped in the memory.stat file. This looks like a
> simple word flip that's gone unnoticed since 2010 (dc10e281f5fc,
> memcg: update documentation).
>
> Signed-off-by: Florian Schmidt
Acked-by: Micha
On Tue 30-01-18 14:38:40, David Rientjes wrote:
> On Tue, 30 Jan 2018, Michal Hocko wrote:
>
> > > > So what is the actual semantic and scope of this policy. Does it apply
> > > > only down the hierarchy. Also how do you compare cgroups with different
> &
ant to introduce lowmem
issues from 32b days. I can see the CMA/Hotplug usecases for
ZONE_MOVABLE but those have their own ways to define zone movable. I was
tempted to simply remove the kernelcore already. Could you be more
specific what is your usecase which triggered a need of an easier
sc
On Wed 14-02-18 02:28:38, David Rientjes wrote:
> On Wed, 14 Feb 2018, Michal Hocko wrote:
>
> > I do not have any objections regarding the extension. What I am more
> > interested in is _why_ people are still using this command line
> > parameter at all these days. W
0.000
> 0.000 0.000
> #
>
> Robert M. Harris (1):
> mm, compaction: correct the bounds of __fragmentation_index()
>
> Documentation/sysctl/vm.txt | 2 +-
> mm/compaction.c | 2 +-
> mm/vmstat.c | 47
> +++--
< F <= 1. In order to inhibit
> + * compaction in the event of a pathological shortfall of memory this
> + * function truncates and returns
> + *
> + * F - 1/info->free_blocks_total
>*/
> - return 1000 - div_u64( (1000+(div_u64(info->free_pages * 1000ULL,
>
On Mon 19-02-18 12:14:26, Robert Harris wrote:
>
>
> > On 19 Feb 2018, at 08:26, Michal Hocko wrote:
> >
> > On Sun 18-02-18 16:47:55, robert.m.har...@oracle.com wrote:
> >> From: "Robert M. Harris"
> >>
> >> __fragm
On Mon 19-02-18 14:30:36, Robert Harris wrote:
>
>
> > On 19 Feb 2018, at 12:39, Michal Hocko wrote:
> >
> > On Mon 19-02-18 12:14:26, Robert Harris wrote:
> >>
> >>
> >>> On 19 Feb 2018, at 08:26, Michal Hocko wrote:
> >>>
the compaction changes over time.
So I would really prefer to kill the tuning than try to "fix" it.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
| 4 ++--
> mm/memory.c | 2 +-
> 23 files changed, 18 insertions(+), 24 deletions(-)
>
> --
> 2.7.4
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
page tables.
>* eg. VDSO mappings can cause them to exist.
>*/
> -out:
> +out: __maybe_unused
> return pfn_to_page(pfn);
Why do we need this ugliness all of the sudden?
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe
ed-by: Jerome Glisse
> Reviewed-by: Jerome Glisse
> Acked-by: David Rientjes
> Signed-off-by: Laurent Dufour
Looks good to me. I have checked x86 and the generic code and it looks
good to me. Anyway arch maintainers really have to double check this.
--
Michal Hocko
SUSE Labs
--
To unsu
On Wed 11-04-18 10:41:23, Laurent Dufour wrote:
> On 11/04/2018 10:33, Michal Hocko wrote:
> > On Wed 11-04-18 10:03:36, Laurent Dufour wrote:
> >> @@ -881,7 +876,8 @@ struct page *_vm_normal_page(struct vm_area_struct
> >> *vma, unsigned long addr,
> &g
On Wed 11-04-18 12:32:07, Laurent Dufour wrote:
[...]
> Andrew, should I send a v4 or could you wipe the 2 __maybe_unsued when
> applying
> the patch ?
A follow $patch-fix should be better rather than post this again and
spam people with more emails.
--
Michal Hocko
SUSE Labs
--
To un
page state.
I am not really sure what is the concern here exactly. Kdump is so
closly tight to the specific kernel version that the api exported
specifically for its purpose cannot be seriously considered an ABI.
Kdump has to adopt all the time.
--
Michal Hocko
SUSE Labs
hen virtio-balloon pages were always marked
> with PG_balloon. So the documentation is actually wrong ("balloon page"
> vs. "balloon compaction page").
>
> I have no idea who actually used that information. I suspect this was
> just some debugging aid.
>
> >
> >> To not break uapi I decided to not rename it but instead to add a new flag.
> >
> > I've got a feeling that uapi was anyway changed for the BALLON flag
> > meaning.
>
> Yes. If we *replace* KPF_BALLOON by KPF_OFFLINE
>
> a) Some applications might no longer compile (I guess that's ok)
> b) Some old applications will treat KPF_OFFLINE like KPF_BALLOON (which
> should at least for virtio-balloon usage until now be fine - it is just
> more generic)
I do not think any compilation could break. If the semantic of the flag
is preserved then everything should work as expected.
--
Michal Hocko
SUSE Labs
ly do not want to touch
offline pfn ranges in general. A separate patch for that of course.
Thanks!
--
Michal Hocko
SUSE Labs
Andrew Morton
> Cc: Matthew Wilcox
> Cc: Michal Hocko
> Cc: "Michael S. Tsirkin"
> Suggested-by: Michal Hocko
> Signed-off-by: David Hildenbrand
I have only a very vague understanding of this specific code but I do
not really see any real reason for checking offl
for anything apart from this accounting AFAIR. The
less ad-hoc code we have the better IMHO.
And to the underlying problem. Some proc files do not scale on large
machines. Maybe it is time to explain that to application writers that
if they are collecting data too agressively then it won't scale. We can
only do this much. Lying about numbers by hiding updates is, well,
lying and won't solve the underlying problem.
--
Michal Hocko
SUSE Labs
(a heavy multithreaded process can still deplete the
reserves completely).
Is there really any reason to not go with the existing patch I've
pointed to the last time around? You didn't seem to have any objects
back then.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the l
On Wed 26-07-17 15:06:07, Roman Gushchin wrote:
> On Wed, Jul 26, 2017 at 03:56:22PM +0200, Michal Hocko wrote:
> > On Wed 26-07-17 14:27:15, Roman Gushchin wrote:
> > [...]
> > > @@ -656,13 +658,24 @@ static void mark_oom_victim(struct task_struct *tsk)
> > >
On Wed 26-07-17 16:24:34, Michal Hocko wrote:
[...]
> Or if you prefer I can post it separately?
I've just tried to rebase relevant parts on top of the current mmotm
tree and it needs some non-trivial updates. Would you mind if I post
those patches with you on CC? I really think that we s
o say I do not quite like how it is
implemented. I was hoping for something much simpler which would hook
into oom_evaluate_task. If a task belongs to a memcg with kill-all flag
then we would update the cumulative memcg badness (more specifically the
badness of the topmost parent with kill-all flag
1 - 100 of 238 matches
Mail list logo
