Re: [PATCH V2] mm/page_alloc: Ensure that HUGETLB_PAGE_ORDER is less than MAX_ORDER

g the buddy order to > > something > MAX_ORDER -1 on that path? > > Agreed. We would need to return the supersized block to the huge page pool and not to the buddy allocator. There is a special callback in the compound page sos that you can call an alternate free function that is not t

Re: [PATCH] infiniband: ulp: Remove unnecessary struct declaration

On Thu, 15 Apr 2021, Wan Jiabing wrote: > struct ipoib_cm_tx is defined at 245th line. > And the definition is independent on the MACRO. > The declaration here is unnecessary. Remove it. Correct. Reviewed-by: Christoph Lameter

Re: [PATCH v3 5/5] mm/memcg: Optimize user context object stock access

On Wed, 14 Apr 2021, Masayoshi Mizuma wrote: > Please feel free to add: > > Tested-by: Masayoshi Mizuma > > Thanks! > Masa > Would you please stop quoting the whole patch when you have nothing to say about the details? It is enough to just respond without quoting. I was looking through this

Re: [PATCH v3 0/4] mm/slub: Fix count_partial() problem

On Mon, 15 Mar 2021, Yang Shi wrote: > > It seems like CONFIG_SLUB_DEBUG is a more popular option than > > CONFIG_SLUB_STATS. > > CONFIG_SLUB_DEBUG is enabled on my Fedora workstation, CONFIG_SLUB_STATS is > > off. > > I doubt an average user needs this data, so I'd go with CONFIG_SLUB_STATS. >

Re: [mm, slub] 8ff60eb052: stress-ng.rawpkt.ops_per_sec -47.9% regression

On Tue, 9 Mar 2021, Linus Torvalds wrote: > So when you wrote: > > However, the current code accidentally stops looking at the partial list > completely in that case. Especially on kernels without CONFIG_NUMA set, > this means that get_partial() fails and new_slab_objects() falls

Re: [PATCH] mm/slub: Add slub_debug option to panic on memory corruption

On Tue, 9 Mar 2021, Georgi Djakov wrote: > Being able to stop the system immediately when a memory corruption > is detected is crucial to finding the source of it. This is very > useful when the memory can be inspected with kdump or other tools. Hmmm ok. > static void restore_bytes(struct

Re: [PATCH v2 3/3] mm/slub: Use percpu partial free counter

On Wed, 3 Mar 2021, Matthew Wilcox wrote: > > Can this be allocated in an interrupt context? > > > > And I am not sure how local_t relates to that? Percpu counters can be used > > in an interrupt context without the overhead of the address calculations > > that are required by a local_t. > > As I

Re: [PATCH v2 3/3] mm/slub: Use percpu partial free counter

On Wed, 3 Mar 2021, Matthew Wilcox wrote: > On Tue, Mar 02, 2021 at 10:14:53AM +0100, Christoph Lameter wrote: > > On Mon, 10 Aug 2020, Xunlei Pang wrote: > > > - atomic_long_t partial_free_objs; > > > + atomic_long_t __percpu *partial_free_objs; > > > > A p

Re: [PATCH] include/linux/slab.h: use for() and left shift to calculate

On Tue, 2 Mar 2021, Yejune Deng wrote: > use for() and left shift to calculate the value that compared with size. There is a reason for the madness... The current code was written so compilers can do proper constant folding and eliminate the whole function entirely. If you want this change

Re: [PATCH v2 3/3] mm/slub: Use percpu partial free counter

On Mon, 10 Aug 2020, Xunlei Pang wrote: > > diff --git a/mm/slab.h b/mm/slab.h > index c85e2fa..a709a70 100644 > --- a/mm/slab.h > +++ b/mm/slab.h > @@ -616,7 +616,7 @@ struct kmem_cache_node { > #ifdef CONFIG_SLUB > unsigned long nr_partial; > struct list_head partial; > -

Re: [RFC PATCH v0] mm/slub: Let number of online CPUs determine the slub page order

On Thu, 4 Feb 2021, Vincent Guittot wrote: > > So what is preferrable here now? Above or other quick fix or reverting > > the original commit? > > I'm fine with whatever the solution as long as we can use keep using > nr_cpu_ids when other values like num_present_cpus, don't reflect > correctly

Re: [PATCH] mm/slub: embed __slab_alloc to its caller

On Tue, 2 Feb 2021, Abel Wu wrote: > Since slab_alloc_node() is the only caller of __slab_alloc(), embed > __slab_alloc() to its caller to save function call overhead. This > will also expand the caller's code block size a bit, but hackbench > tests on both host and guest didn't show a difference

Re: [PATCH v16 07/11] secretmem: use PMD-size pages to amortize direct map fragmentation

On Thu, 28 Jan 2021, Michal Hocko wrote: > > > If you kill the allocating process then yes, it would work, but your > > > process might be the very last to be selected. > > > > OOMs are different if you have a "constrained allocation". In that case it > > is the fault of the process who wanted

Re: [PATCH v16 07/11] secretmem: use PMD-size pages to amortize direct map fragmentation

On Thu, 28 Jan 2021, Michal Hocko wrote: > > So, if I understand your concerns correct this implementation has two > > issues: > > 1) allocation failure at page fault that causes unrecoverable OOM and > > 2) a possibility for an unprivileged user to deplete secretmem pool and > > cause (1) to

Re: [RFC PATCH v0] mm/slub: Let number of online CPUs determine the slub page order

On Tue, 26 Jan 2021, Will Deacon wrote: > > Hm, but booting the secondaries is just a software (kernel) action? They are > > already physically there, so it seems to me as if the cpu_present_mask is > > not > > populated correctly on arm64, and it's just a mirror of cpu_online_mask? > > I think

Re: [PATCH 1/1] arm64/sparsemem: reduce SECTION_SIZE_BITS

On Wed, 20 Jan 2021, Sudarshan Rajagopalan wrote: > But there are other problems in reducing SECTION_SIZE_BIT. Reducing it by too > much would over populate /sys/devices/system/memory/ and also consume too many > page->flags bits in the !vmemmap case. Also section size needs to be multiple > of

Re: [RFC PATCH v0] mm/slub: Let number of online CPUs determine the slub page order

On Thu, 21 Jan 2021, Bharata B Rao wrote: > > The problem is that calculate_order() is called a number of times > > before secondaries CPUs are booted and it returns 1 instead of 224. > > This makes the use of num_online_cpus() irrelevant for those cases > > > > After adding in my command line

Re: SLUB: percpu partial object count is highly inaccurate, causing some memory wastage and maybe also worse tail latencies?

On Mon, 18 Jan 2021, Michal Hocko wrote: > > Hm this would be similar to recommending a periodical echo > drop_caches > > operation. We actually discourage from that (and yeah, some tools do that, > > and > > we now report those in dmesg). I believe the kernel should respond to memory > >

Re: SLUB: percpu partial object count is highly inaccurate, causing some memory wastage and maybe also worse tail latencies?

On Wed, 13 Jan 2021, Jann Horn wrote: > Some brainstorming: > > Maybe you could have an atomic counter in kmem_cache_cpu that tracks > the number of empty frozen pages that are associated with a specific > CPU? So the freeing slowpath would do its cmpxchg_double, and if the The latencies of

Re: SLUB: percpu partial object count is highly inaccurate, causing some memory wastage and maybe also worse tail latencies?

On Tue, 12 Jan 2021, Jann Horn wrote: > [This is not something I intend to work on myself. But since I > stumbled over this issue, I figured I should at least document/report > it, in case anyone is willing to pick it up.] Well yeah all true. There is however a slabinfo tool that has an -s

Re: [PATCH] MAINTAINERS: add myself as slab allocators maintainer

I am ok with you as a slab maintainer. I have seen some good work from you. Acked-by: Christoph Lameter

Re: [RFC 0/3] mm, slab, slub: remove cpu and memory hotplug locks

On Wed, 6 Jan 2021, Vlastimil Babka wrote: > rather accept some wasted memory in scenarios that should be rare anyway (full > memory hot remove), as we do the same in other contexts already. It's all RFC > for now, as I might have missed some reason why it's not safe. Looks good to me. My only

Re: [PATCH] mm/slub: fix -Wunused-function compiler warnings

On Tue, 17 Sep 2019, David Rientjes wrote: > Acked-by: David Rientjes Ditto

Re: [PATCH] mm/slub: fix -Wunused-function compiler warnings

On Tue, 17 Sep 2019, David Rientjes wrote: > On Tue, 17 Sep 2019, Qian Cai wrote: > > > tid_to_cpu() and tid_to_event() are only used in note_cmpxchg_failure() > > when SLUB_DEBUG_CMPXCHG=y, so when SLUB_DEBUG_CMPXCHG=n by default, > > Clang will complain that those unused functions. > > > >

[RFC 1/7] slub: Replace ctor field with ops field in /sys/slab/*

-by: Christoph Lameter --- mm/slub.c | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) Index: linux/mm/slub.c === --- linux.orig/mm/slub.c +++ linux/mm/slub.c @@ -4994,13 +4994,18 @@ static ssize_t cpu_partial_store

[RFC 6/7] slub: Extend slabinfo to support -D and -F options

-off-by: Christoph Lameter --- Documentation/vm/slabinfo.c | 48 +++- 1 file changed, 43 insertions(+), 5 deletions(-) Index: linux/tools/vm/slabinfo.c === --- linux.orig/tools/vm/slabinfo.c

[RFC 7/7] xarray: Implement migration function for objects

Implement functions to migrate objects. This is based on initial code by Matthew Wilcox and was modified to work with slab object migration. Signed-off-by: Christoph Lameter Index: linux/lib/radix-tree.c === --- linux.orig/lib

[RFC 4/7] slub: Sort slab cache list and establish maximum objects for defrag slabs

. This allows the sizing of the array holding refs to objects in a slab later. Signed-off-by: Christoph Lameter --- mm/slub.c | 26 -- 1 file changed, 24 insertions(+), 2 deletions(-) Index: linux/mm/slub.c

[RFC 3/7] slub: Add isolate() and migrate() methods

for SLAB/SLOB. The API is generic so it could be theoretically implemented for these allocators as well. Signed-off-by: Christoph Lameter --- include/linux/slab.h | 50 +++ include/linux/slub_def.h |3 ++ mm/slub.c| 29

[RFC 5/7] slub: Slab defrag core

objects were removed then the slab is freed and we have reduced the overall fragmentation of the slab cache. Signed-off-by: Christoph Lameter --- include/linux/slab.h |3 mm/slub.c| 265 --- 2 files changed, 215

[RFC 2/7] slub: Add defrag_ratio field and sysfs support

ation. Add a defrag ratio field and set it to 30% by default. A limit of 30% specifies that less than 3 out of 10 available slots for objects need to be leftover before slab defragmentation will be attempted on the remaining objects. Signed-off-by: Christoph Lameter --- Documentation/ABI/testi

[RFC 0/7] Slab object migration for xarray V2

V1->V2: - Works now on top of 4.20-rc7 - A couple of bug fixes This is a patchset on top of Matthew Wilcox Xarray code and implements slab object migration for xarray nodes. The migration is integrated into the defragmetation and shrinking logic of the slab allocator.

Re: [PATCH] vmemmap, memory_hotplug: fallback to base pages for vmmap

On Tue, 11 Jul 2017, Johannes Weiner wrote: > Hi Michael, > > On Tue, Jul 11, 2017 at 04:25:58PM +0200, Michal Hocko wrote: > > Ohh, scratch that. The patch is bogus. I have completely missed that > > vmemmap_populate_hugepages already falls back to > > vmemmap_populate_basepages. I have to

Re: [PATCH] vmemmap, memory_hotplug: fallback to base pages for vmmap

On Tue, 11 Jul 2017, Johannes Weiner wrote: > Hi Michael, > > On Tue, Jul 11, 2017 at 04:25:58PM +0200, Michal Hocko wrote: > > Ohh, scratch that. The patch is bogus. I have completely missed that > > vmemmap_populate_hugepages already falls back to > > vmemmap_populate_basepages. I have to

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On Tue, 11 Jul 2017, Frederic Weisbecker wrote: > > --- a/kernel/time/tick-sched.c > > +++ b/kernel/time/tick-sched.c > > @@ -787,6 +787,7 @@ static ktime_t tick_nohz_stop_sched_tick(struct > > tick_sched *ts, > > if (!ts->tick_stopped) { > > calc_load_nohz_start(); > >

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

On Tue, 11 Jul 2017, Frederic Weisbecker wrote: > > --- a/kernel/time/tick-sched.c > > +++ b/kernel/time/tick-sched.c > > @@ -787,6 +787,7 @@ static ktime_t tick_nohz_stop_sched_tick(struct > > tick_sched *ts, > > if (!ts->tick_stopped) { > > calc_load_nohz_start(); > >

Re: [PATCH] slub: make sure struct kmem_cache_node is initialized before publication

On Mon, 10 Jul 2017, Alexander Potapenko wrote: > >> Could the slab maintainers please take a look at these and also have a > >> think about Alexander's READ_ONCE/WRITE_ONCE question? > > > > Was I cced on these? > I've asked Andrew about READ_ONCE privately. Please post to a mailing list and cc

Re: [PATCH] slub: make sure struct kmem_cache_node is initialized before publication

On Mon, 10 Jul 2017, Alexander Potapenko wrote: > >> Could the slab maintainers please take a look at these and also have a > >> think about Alexander's READ_ONCE/WRITE_ONCE question? > > > > Was I cced on these? > I've asked Andrew about READ_ONCE privately. Please post to a mailing list and cc

Re: [PATCH] slub: make sure struct kmem_cache_node is initialized before publication

On Fri, 7 Jul 2017, Andrew Morton wrote: > On Fri, 7 Jul 2017 10:34:08 +0200 Alexander Potapenko > wrote: > > > --- a/mm/slub.c > > +++ b/mm/slub.c > > @@ -3389,8 +3389,8 @@ static int init_kmem_cache_nodes(struct kmem_cache *s) > > return 0; > >

Re: [PATCH] slub: make sure struct kmem_cache_node is initialized before publication

On Fri, 7 Jul 2017, Andrew Morton wrote: > On Fri, 7 Jul 2017 10:34:08 +0200 Alexander Potapenko > wrote: > > > --- a/mm/slub.c > > +++ b/mm/slub.c > > @@ -3389,8 +3389,8 @@ static int init_kmem_cache_nodes(struct kmem_cache *s) > > return 0; > > } > > > > -

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Fri, 7 Jul 2017, Kees Cook wrote: > If we also added a >0 offset, that would make things even less > deterministic. Though I wonder if it would make the performance impact > higher. The XOR patch right now is very light. There would be barely any performance impact if you keep the offset

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Fri, 7 Jul 2017, Kees Cook wrote: > If we also added a >0 offset, that would make things even less > deterministic. Though I wonder if it would make the performance impact > higher. The XOR patch right now is very light. There would be barely any performance impact if you keep the offset

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Thu, 6 Jul 2017, Kees Cook wrote: > Right. This is about blocking the escalation of attack capability. For > slab object overflow flaws, there are mainly two exploitation methods: > adjacent allocated object overwrite and adjacent freed object > overwrite (i.e. a freelist pointer overwrite).

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Thu, 6 Jul 2017, Kees Cook wrote: > Right. This is about blocking the escalation of attack capability. For > slab object overflow flaws, there are mainly two exploitation methods: > adjacent allocated object overwrite and adjacent freed object > overwrite (i.e. a freelist pointer overwrite).

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Thu, 6 Jul 2017, Kees Cook wrote: > On Thu, Jul 6, 2017 at 6:43 AM, Christoph Lameter <c...@linux.com> wrote: > > On Wed, 5 Jul 2017, Kees Cook wrote: > > > >> @@ -3536,6 +3565,9 @@ static int kmem_cache_open(struct kmem_cache *s, > >> unsigned

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Thu, 6 Jul 2017, Kees Cook wrote: > On Thu, Jul 6, 2017 at 6:43 AM, Christoph Lameter wrote: > > On Wed, 5 Jul 2017, Kees Cook wrote: > > > >> @@ -3536,6 +3565,9 @@ static int kmem_cache_open(struct kmem_cache *s, > >> unsigned long flags) > >>

Re: [PATCH] mm: make allocation counters per-order

On Thu, 6 Jul 2017, Roman Gushchin wrote: > +#define PGALLOC_EVENTS_SIZE (MAX_NR_ZONES * MAX_ORDER) > +#define PGALLOC_EVENTS_CUT_SIZE (MAX_NR_ZONES * (MAX_ORDER - 1)) > +#define PGALLOC_FIRST_ZONE (PGALLOC_NORMAL - ZONE_NORMAL) You are significantly increasing the per cpu counters (ZONES *

Re: [PATCH] mm: make allocation counters per-order

On Thu, 6 Jul 2017, Roman Gushchin wrote: > +#define PGALLOC_EVENTS_SIZE (MAX_NR_ZONES * MAX_ORDER) > +#define PGALLOC_EVENTS_CUT_SIZE (MAX_NR_ZONES * (MAX_ORDER - 1)) > +#define PGALLOC_FIRST_ZONE (PGALLOC_NORMAL - ZONE_NORMAL) You are significantly increasing the per cpu counters (ZONES *

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Wed, 5 Jul 2017, Kees Cook wrote: > @@ -3536,6 +3565,9 @@ static int kmem_cache_open(struct kmem_cache *s, > unsigned long flags) > { > s->flags = kmem_cache_flags(s->size, flags, s->name, s->ctor); > s->reserved = 0; > +#ifdef CONFIG_SLAB_FREELIST_HARDENED > + s->random =

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Wed, 5 Jul 2017, Kees Cook wrote: > @@ -3536,6 +3565,9 @@ static int kmem_cache_open(struct kmem_cache *s, > unsigned long flags) > { > s->flags = kmem_cache_flags(s->size, flags, s->name, s->ctor); > s->reserved = 0; > +#ifdef CONFIG_SLAB_FREELIST_HARDENED > + s->random =

Re: [PATCH v2] mm: Add SLUB free list pointer obfuscation

On Sun, 25 Jun 2017, Kees Cook wrote: > The difference gets lost in the noise, but if the above is sensible, > it's 0.07% slower. ;) Hmmm... These differences add up. Also in a repetative benchmark like that you do not see the impact that the additional cacheline use in the cpu cache has on

Re: [PATCH v2] mm: Add SLUB free list pointer obfuscation

On Sun, 25 Jun 2017, Kees Cook wrote: > The difference gets lost in the noise, but if the above is sensible, > it's 0.07% slower. ;) Hmmm... These differences add up. Also in a repetative benchmark like that you do not see the impact that the additional cacheline use in the cpu cache has on

Re: [PATCH] slub: make sysfs file removal asynchronous

On Tue, 20 Jun 2017, Tejun Heo wrote: > And we have to weight that against the possibility of breakage from > the backport, however low it may be, right? I'm not strongly > convinced either way on this one and AFAICS the slub sysfs files there > are mostly for debugging, so we'd be risking

Re: [PATCH] slub: make sysfs file removal asynchronous

On Tue, 20 Jun 2017, Tejun Heo wrote: > And we have to weight that against the possibility of breakage from > the backport, however low it may be, right? I'm not strongly > convinced either way on this one and AFAICS the slub sysfs files there > are mostly for debugging, so we'd be risking

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

On Fri, 26 May 2017, Marcelo Tosatti wrote: > > interrupts and scheduler ticks. But what does this have to do with vmstat? > > > > Show me your dpdk code running and trace the tick on / off events as well > > as the vmstat invocations. Also show all system calls occurring on the cpu > > that

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

On Fri, 26 May 2017, Marcelo Tosatti wrote: > > interrupts and scheduler ticks. But what does this have to do with vmstat? > > > > Show me your dpdk code running and trace the tick on / off events as well > > as the vmstat invocations. Also show all system calls occurring on the cpu > > that

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

On Thu, 25 May 2017, Marcelo Tosatti wrote: > Argument? We're showing you the data that this is causing a latency > problem for us. Sorry I am not sure where the data shows a latency problem. There are interrupts and scheduler ticks. But what does this have to do with vmstat? Show me your dpdk

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

On Thu, 25 May 2017, Marcelo Tosatti wrote: > Argument? We're showing you the data that this is causing a latency > problem for us. Sorry I am not sure where the data shows a latency problem. There are interrupts and scheduler ticks. But what does this have to do with vmstat? Show me your dpdk

Re: [PATCH 0/6] refine and rename slub sysfs

On Wed, 24 May 2017, Wei Yang wrote: > > > >Who is going to use those new entries and for what purpose? Why do we > >want to expose even more details of the slab allocator to the userspace. > >Is the missing information something fundamental that some user space > >cannot work without it?

Re: [PATCH 0/6] refine and rename slub sysfs

On Wed, 24 May 2017, Wei Yang wrote: > > > >Who is going to use those new entries and for what purpose? Why do we > >want to expose even more details of the slab allocator to the userspace. > >Is the missing information something fundamental that some user space > >cannot work without it?

Re: [PATCH 0/6] refine and rename slub sysfs

On Tue, 23 May 2017, Michal Hocko wrote: > > >_Why_ do we need all this? > > > > To have a clear statistics for each slab level. > > Is this worth risking breakage of the userspace which consume this data > now? Do you have any user space code which will greatly benefit from the > new data and

Re: [PATCH 0/6] refine and rename slub sysfs

On Tue, 23 May 2017, Michal Hocko wrote: > > >_Why_ do we need all this? > > > > To have a clear statistics for each slab level. > > Is this worth risking breakage of the userspace which consume this data > now? Do you have any user space code which will greatly benefit from the > new data and

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

On Sat, 20 May 2017, Marcelo Tosatti wrote: > > And you can configure the interval of vmstat updates freely Set > > the vmstat_interval to 60 seconds instead of 2 for a try? Is that rare > > enough? > > Not rare enough. Never is rare enough. Ok what about the other stuff that must be going

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

On Sat, 20 May 2017, Marcelo Tosatti wrote: > > And you can configure the interval of vmstat updates freely Set > > the vmstat_interval to 60 seconds instead of 2 for a try? Is that rare > > enough? > > Not rare enough. Never is rare enough. Ok what about the other stuff that must be going

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

On Fri, 19 May 2017, Luiz Capitulino wrote: > Something that crossed my mind was to add a new tunable to set > the vmstat_interval for each CPU, this way we could essentially > disable it to the CPUs where DPDK is running. What's the implications > of doing this besides not getting up to date

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

On Fri, 19 May 2017, Luiz Capitulino wrote: > Something that crossed my mind was to add a new tunable to set > the vmstat_interval for each CPU, this way we could essentially > disable it to the CPUs where DPDK is running. What's the implications > of doing this besides not getting up to date

Re: [PATCH 0/3] mm/slub: Fix unused function warnings

On Fri, 19 May 2017, Matthias Kaehlcke wrote: > This series fixes a bunch of warnings about unused functions in SLUB Looks ok to me. Acked-by: Christoph Lameter <c...@linux.com>

Re: [PATCH 0/3] mm/slub: Fix unused function warnings

On Fri, 19 May 2017, Matthias Kaehlcke wrote: > This series fixes a bunch of warnings about unused functions in SLUB Looks ok to me. Acked-by: Christoph Lameter

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

On Fri, 19 May 2017, Marcelo Tosatti wrote: > Use-case: realtime application on an isolated core which for some reason > updates vmstatistics. Ok that is already only happening every 2 seconds by default and that interval is configurable via the vmstat_interval proc setting. > > Just a

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

On Fri, 19 May 2017, Marcelo Tosatti wrote: > Use-case: realtime application on an isolated core which for some reason > updates vmstatistics. Ok that is already only happening every 2 seconds by default and that interval is configurable via the vmstat_interval proc setting. > > Just a

Re: Virtually Mapped Stacks: Do not disable interrupts

On Thu, 18 May 2017, Andy Lutomirski wrote: > On Wed, May 17, 2017 at 8:58 AM, Christoph Lameter <c...@linux.com> wrote: > > The reason to disable interrupts seems to be to avoid switching > > to a different processor while handling per cpu data using > > individual

Re: Virtually Mapped Stacks: Do not disable interrupts

On Thu, 18 May 2017, Andy Lutomirski wrote: > On Wed, May 17, 2017 at 8:58 AM, Christoph Lameter wrote: > > The reason to disable interrupts seems to be to avoid switching > > to a different processor while handling per cpu data using > > individual loads and stores.

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

On Thu, 18 May 2017, Michal Hocko wrote: > > See above. OOM Kill in a cpuset does not kill an innocent task but a task > > that does an allocation in that specific context meaning a task in that > > cpuset that also has a memory policty. > > No, the oom killer will chose the largest task in the

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

On Thu, 18 May 2017, Michal Hocko wrote: > > See above. OOM Kill in a cpuset does not kill an innocent task but a task > > that does an allocation in that specific context meaning a task in that > > cpuset that also has a memory policty. > > No, the oom killer will chose the largest task in the

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

On Thu, 18 May 2017, Vlastimil Babka wrote: > > The race is where? If you expand the node set during the move of the > > application then you are safe in terms of the legacy apps that did not > > include static bindings. > > No, that expand/shrink by itself doesn't work against parallel

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

On Thu, 18 May 2017, Vlastimil Babka wrote: > > The race is where? If you expand the node set during the move of the > > application then you are safe in terms of the legacy apps that did not > > include static bindings. > > No, that expand/shrink by itself doesn't work against parallel

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

On Thu, 18 May 2017, Michal Hocko wrote: > > Nope. The OOM in a cpuset gets the process doing the alloc killed. Or what > > that changed? ! > > > > At this point you have messed up royally and nothing is going to rescue > > you anyways. OOM or not does not matter anymore. The app will fail.

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

On Thu, 18 May 2017, Michal Hocko wrote: > > Nope. The OOM in a cpuset gets the process doing the alloc killed. Or what > > that changed? ! > > > > At this point you have messed up royally and nothing is going to rescue > > you anyways. OOM or not does not matter anymore. The app will fail.

Virtually Mapped Stacks: Do not disable interrupts

The reason to disable interrupts seems to be to avoid switching to a different processor while handling per cpu data using individual loads and stores. If we use per cpu RMV primitives we will not have to disable interrupts. Signed-off-by: Christoph Lameter <c...@linux.com> Index: linux/

Virtually Mapped Stacks: Do not disable interrupts

The reason to disable interrupts seems to be to avoid switching to a different processor while handling per cpu data using individual loads and stores. If we use per cpu RMV primitives we will not have to disable interrupts. Signed-off-by: Christoph Lameter Index: linux/kernel/fork.c

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

On Wed, 17 May 2017, Michal Hocko wrote: > > The race is where? If you expand the node set during the move of the > > application then you are safe in terms of the legacy apps that did not > > include static bindings. > > I am pretty sure it is describe in those changelogs and I won't repeat > it

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

On Wed, 17 May 2017, Michal Hocko wrote: > > The race is where? If you expand the node set during the move of the > > application then you are safe in terms of the legacy apps that did not > > include static bindings. > > I am pretty sure it is describe in those changelogs and I won't repeat > it

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

On Wed, 17 May 2017, Michal Hocko wrote: > > If you have screwy things like static mbinds in there then you are > > hopelessly lost anyways. You may have moved the process to another set > > of nodes but the static bindings may refer to a node no longer > > available. Thus the OOM is legitimate.

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

On Wed, 17 May 2017, Michal Hocko wrote: > > If you have screwy things like static mbinds in there then you are > > hopelessly lost anyways. You may have moved the process to another set > > of nodes but the static bindings may refer to a node no longer > > available. Thus the OOM is legitimate.

Re: [PATCH v2 3/6] mm, page_alloc: pass preferred nid instead of zonelist to allocator

to use zonelists instead of nodes back then but cannot remember what that reason was CCing Dimitri at SGI. This may break a lot of legacy SGIapps. If you read this Dimitri then please review this patchset and the discussions around it. Reviewed-by: Christoph Lameter <c...@linux.com>

Re: [PATCH v2 3/6] mm, page_alloc: pass preferred nid instead of zonelist to allocator

to use zonelists instead of nodes back then but cannot remember what that reason was CCing Dimitri at SGI. This may break a lot of legacy SGIapps. If you read this Dimitri then please review this patchset and the discussions around it. Reviewed-by: Christoph Lameter

Re: [PATCH v2 2/6] mm, mempolicy: stop adjusting current->il_next in mpol_rebind_nodemask()

re that current->il_next is valid within the updated nodemask. This is > bogus, because 1) we are updating potentially any task's mempolicy, not just > current, and 2) we might be updating a per-vma mempolicy, not task one. Reviewed-by: Christoph Lameter <c...@linux.com>

Re: [PATCH v2 2/6] mm, mempolicy: stop adjusting current->il_next in mpol_rebind_nodemask()

re that current->il_next is valid within the updated nodemask. This is > bogus, because 1) we are updating potentially any task's mempolicy, not just > current, and 2) we might be updating a per-vma mempolicy, not task one. Reviewed-by: Christoph Lameter

Re: [PATCH 0/6] refine and rename slub sysfs

On Wed, 17 May 2017, Wei Yang wrote: > This patch serial could be divided into two parts. > > First three patches refine and adds slab sysfs. > Second three patches rename slab sysfs. These changes will break the slabinfo tool in linux/tools/vm/slabinfo.c. Please update it as well. > 1. Refine

Re: [PATCH 0/6] refine and rename slub sysfs

On Wed, 17 May 2017, Wei Yang wrote: > This patch serial could be divided into two parts. > > First three patches refine and adds slab sysfs. > Second three patches rename slab sysfs. These changes will break the slabinfo tool in linux/tools/vm/slabinfo.c. Please update it as well. > 1. Refine

Re: [PATCH 1/6] mm/slub: add total_objects_partial sysfs

On Wed, 17 May 2017, Wei Yang wrote: > For partial slabs, show_slab_objects could display its total objects. > > This patch just adds an entry to display it. Acked-by: Christoph Lameter <c...@linux.com>

Re: [PATCH 1/6] mm/slub: add total_objects_partial sysfs

On Wed, 17 May 2017, Wei Yang wrote: > For partial slabs, show_slab_objects could display its total objects. > > This patch just adds an entry to display it. Acked-by: Christoph Lameter

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

On Wed, 17 May 2017, Michal Hocko wrote: > > > So how are you going to distinguish VM_FAULT_OOM from an empty mempolicy > > > case in a raceless way? > > > > You dont have to do that if you do not create an empty mempolicy in the > > first place. The current kernel code avoids that by first

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

On Wed, 17 May 2017, Michal Hocko wrote: > > > So how are you going to distinguish VM_FAULT_OOM from an empty mempolicy > > > case in a raceless way? > > > > You dont have to do that if you do not create an empty mempolicy in the > > first place. The current kernel code avoids that by first

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

On Wed, 17 May 2017, Michal Hocko wrote: > > We certainly can do that. The failure of the page faults are due to the > > admin trying to move an application that is not aware of this and is using > > mempols. That could be an error. Trying to move an application that > > contains both absolute

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

On Wed, 17 May 2017, Michal Hocko wrote: > > We certainly can do that. The failure of the page faults are due to the > > admin trying to move an application that is not aware of this and is using > > mempols. That could be an error. Trying to move an application that > > contains both absolute

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

On Mon, 15 May 2017, Marcelo Tosatti wrote: > > NOHZ already does that. I wanted to know what your problem is that you > > see. The latency issue has already been solved as far as I can tell . > > Please tell me why the existing solutions are not sufficient for you. > > We don't want

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

On Mon, 15 May 2017, Marcelo Tosatti wrote: > > NOHZ already does that. I wanted to know what your problem is that you > > see. The latency issue has already been solved as far as I can tell . > > Please tell me why the existing solutions are not sufficient for you. > > We don't want

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

On Fri, 12 May 2017, Marcelo Tosatti wrote: > > What exactly is the issue you are seeing and want to address? I think we > > have similar aims and as far as I know the current situation is already > > good enough for what you may need. You may just not be aware of how to > > configure this. > > I

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

On Fri, 12 May 2017, Marcelo Tosatti wrote: > > What exactly is the issue you are seeing and want to address? I think we > > have similar aims and as far as I know the current situation is already > > good enough for what you may need. You may just not be aware of how to > > configure this. > > I

  1   2   3   4   5   6   7   8   9   10   >