Re: [osv-dev] GDB stub

On Mon., Feb. 8, 2021, 3:00 a.m. Nadav Har'El, wrote: > On Wed, Feb 3, 2021 at 1:18 AM Waldek Kozaczuk > wrote: > >> Currently, it is only possible to connect from gdb to a running instance >> of OSv on QEMU. But ideally, it would be nice to have a gdb stub in OSv >> that would let one connect

Re: [PATCH v1 0/2] Add timeout mechanism to qmp actions

On Tue, Dec 8, 2020 at 8:11 AM Stefan Hajnoczi wrote: > > On Thu, Oct 22, 2020 at 05:29:16PM +0100, Fam Zheng wrote: > > On Tue, 2020-10-20 at 09:34 +0800, Zhenyu Ye wrote: > > > On 2020/10/19 21:25, Paolo Bonzini wrote: > > > > On 19/10/20 14:40, Zhenyu Ye wrote: > > > > > The kernel backtrace

Re: [PATCH v1 0/2] Add timeout mechanism to qmp actions

On Tue, Dec 8, 2020 at 8:11 AM Stefan Hajnoczi wrote: > > On Thu, Oct 22, 2020 at 05:29:16PM +0100, Fam Zheng wrote: > > On Tue, 2020-10-20 at 09:34 +0800, Zhenyu Ye wrote: > > > On 2020/10/19 21:25, Paolo Bonzini wrote: > > > > On 19/10/20 14:40, Zhenyu Ye wrote: > > > > > The kernel backtrace

Re: Evolving the client protocol

BTW, Folks from Cassandra apparently didn'tr eceive this message. On Wed, Apr 18, 2018 at 6:47 AM, Avi Kivity wrote: > Hello Cassandra developers, > > > We're starting to see client protocol limitations impact performance, and > so we'd like to evolve the protocol to remove

Re: [PATCH] cfq: fix starvation of asynchronous writes

On Fri, Sep 23, 2016 at 7:28 AM, Glauber Costa <glau...@scylladb.com> wrote: > On Sep 23, 2016 6:22 AM, "Paolo Valente" <paolo.vale...@unimore.it> wrote: >> >> >> > Il giorno 23 set 2016, alle ore 02:59, Glauber Costa >> > <glau...@sc

Re: [PATCH] cfq: fix starvation of asynchronous writes

On Fri, Sep 23, 2016 at 7:28 AM, Glauber Costa wrote: > On Sep 23, 2016 6:22 AM, "Paolo Valente" wrote: >> >> >> > Il giorno 23 set 2016, alle ore 02:59, Glauber Costa >> > ha scritto: >> > >> > While debugging timeouts happening in

Re: [PATCH] cfq: fix starvation of asynchronous writes

On Fri, Sep 23, 2016 at 7:28 AM, Glauber Costa <glau...@scylladb.com> wrote: > On Sep 23, 2016 6:22 AM, "Paolo Valente" <paolo.vale...@unimore.it> wrote: >> >> >> > Il giorno 23 set 2016, alle ore 02:59, Glauber Costa >> > <glau...@sc

[PATCH] cfq: fix starvation of asynchronous writes

0 65536 | 0 131072 | 1 262144 | 0 524288 | 0 Signed-off-by: Glauber

[PATCH] cfq: fix starvation of asynchronous writes

0 65536 | 0 131072 | 1 262144 | 0 524288 | 0 Signed-off-by: Glaub

Re: ScyllaDB on OSv?

On Fri, Aug 12, 2016 at 3:26 PM, Roman Shaposhnik wrote: > On Fri, Aug 12, 2016 at 10:33 AM, Avi Kivity wrote: > > On 08/12/2016 08:23 PM, Waldek Kozaczuk wrote: > >> > >> Given that ScyllaDB uses seastar that can run on OSv is it possible to > run > >>

Re: [BUG] Paravirtual time accounting / IRQ time accounting

On Wed, Mar 19, 2014 at 6:42 AM, wrote: > In consolidated environments, when there are multiple virtual machines (VMs) > running on one CPU core, timekeeping will be a problem to the guest OS. > Here, I report my findings about Linux process scheduler. > > > Description > > Linux

Re: [BUG] Paravirtual time accounting / IRQ time accounting

On Wed, Mar 19, 2014 at 6:42 AM, lwch...@cs.hku.hk wrote: In consolidated environments, when there are multiple virtual machines (VMs) running on one CPU core, timekeeping will be a problem to the guest OS. Here, I report my findings about Linux process scheduler. Description

Re: [OpenZFS Developer] Shared Page Cache

On Wed, Feb 5, 2014 at 10:03 PM, Matthew Ahrens mahr...@delphix.com wrote: On Wed, Feb 5, 2014 at 2:31 AM, Glauber Costa glom...@cloudius-systems.com wrote: Hi I've been recently trying to devise some mechanism to reuse the ARC buffers directly into a file back mapping (created by mmap

Re: [PATCH 3/8] memcg, slab: never try to merge memcg caches

On Tue, Feb 4, 2014 at 8:04 PM, Vladimir Davydov wrote: > On 02/04/2014 07:43 PM, Glauber Costa wrote: >> On Tue, Feb 4, 2014 at 7:27 PM, Vladimir Davydov >> wrote: >>> On 02/04/2014 07:11 PM, Michal Hocko wrote: >>>> On Tue 04-02-14 18:59:23, Vladimir Davy

Re: [PATCH 3/8] memcg, slab: never try to merge memcg caches

On Tue, Feb 4, 2014 at 7:27 PM, Vladimir Davydov wrote: > On 02/04/2014 07:11 PM, Michal Hocko wrote: >> On Tue 04-02-14 18:59:23, Vladimir Davydov wrote: >>> On 02/04/2014 06:52 PM, Michal Hocko wrote: On Sun 02-02-14 20:33:48, Vladimir Davydov wrote: > Suppose we are creating memcg

Re: [PATCH 3/8] memcg, slab: never try to merge memcg caches

On Tue, Feb 4, 2014 at 7:27 PM, Vladimir Davydov vdavy...@parallels.com wrote: On 02/04/2014 07:11 PM, Michal Hocko wrote: On Tue 04-02-14 18:59:23, Vladimir Davydov wrote: On 02/04/2014 06:52 PM, Michal Hocko wrote: On Sun 02-02-14 20:33:48, Vladimir Davydov wrote: Suppose we are creating

Re: [PATCH 3/8] memcg, slab: never try to merge memcg caches

On Tue, Feb 4, 2014 at 8:04 PM, Vladimir Davydov vdavy...@parallels.com wrote: On 02/04/2014 07:43 PM, Glauber Costa wrote: On Tue, Feb 4, 2014 at 7:27 PM, Vladimir Davydov vdavy...@parallels.com wrote: On 02/04/2014 07:11 PM, Michal Hocko wrote: On Tue 04-02-14 18:59:23, Vladimir Davydov

Re: [Devel] [PATCH 3/8] memcg, slab: never try to merge memcg caches

On Tue, Feb 4, 2014 at 7:27 PM, Vladimir Davydov vdavy...@parallels.com wrote: On 02/04/2014 07:11 PM, Michal Hocko wrote: On Tue 04-02-14 18:59:23, Vladimir Davydov wrote: On 02/04/2014 06:52 PM, Michal Hocko wrote: On Sun 02-02-14 20:33:48, Vladimir Davydov wrote: Suppose we are creating

Re: [PATCH 1/8] memcg: export kmemcg cache id via cgroup fs

On Mon, Feb 3, 2014 at 10:57 AM, Vladimir Davydov wrote: > On 02/03/2014 10:21 AM, David Rientjes wrote: >> On Sun, 2 Feb 2014, Vladimir Davydov wrote: >> >>> Per-memcg kmem caches are named as follows: >>> >>> (:) >>> >>> where is the unique id of the memcg the cache belongs >>> to, is the

Re: [PATCH 1/8] memcg: export kmemcg cache id via cgroup fs

On Mon, Feb 3, 2014 at 10:57 AM, Vladimir Davydov vdavy...@parallels.com wrote: On 02/03/2014 10:21 AM, David Rientjes wrote: On Sun, 2 Feb 2014, Vladimir Davydov wrote: Per-memcg kmem caches are named as follows: global-cache-name(cgroup-kmem-id:cgroup-name) where cgroup-kmem-id is the

Re: [Devel] [PATCH 1/8] memcg: export kmemcg cache id via cgroup fs

On Mon, Feb 3, 2014 at 10:57 AM, Vladimir Davydov vdavy...@parallels.com wrote: On 02/03/2014 10:21 AM, David Rientjes wrote: On Sun, 2 Feb 2014, Vladimir Davydov wrote: Per-memcg kmem caches are named as follows: global-cache-name(cgroup-kmem-id:cgroup-name) where cgroup-kmem-id is the

Re: [PATCH v14 16/18] vmpressure: in-kernel notifications

On Fri, Dec 20, 2013 at 8:53 PM, Luiz Capitulino wrote: > On Fri, 20 Dec 2013 20:46:05 +0400 > Glauber Costa wrote: > >> On Fri, Dec 20, 2013 at 8:44 PM, Luiz Capitulino >> wrote: >> > On Fri, 20 Dec 2013 10:03:32 -0500 >> > Luiz Capitulino wrote:

Re: [PATCH v14 16/18] vmpressure: in-kernel notifications

On Fri, Dec 20, 2013 at 8:44 PM, Luiz Capitulino wrote: > On Fri, 20 Dec 2013 10:03:32 -0500 > Luiz Capitulino wrote: > >> > The answer for all of your questions above can be summarized by noting >> > that for the lack of other users (at the time), this patch does the bare >> > minimum >> > for

Re: [PATCH v14 16/18] vmpressure: in-kernel notifications

One correction: >> int vmpressure_register_kernel_event(struct cgroup_subsys_state *css, >> - void (*fn)(void)) >> +void (*fn)(void *data, int level), void >> *data) >> { >> - struct vmpressure *vmpr =

Re: [PATCH v14 16/18] vmpressure: in-kernel notifications

Please note that due to my lack of understanding of each shrinker user, >> I will stay away from converting the actual users, you are all welcome >> to do so. >> >> Signed-off-by: Glauber Costa >> Signed-off-by: Vladimir Davydov >> Acked-by: Anton Vorontsov >>

Re: [PATCH v14 16/18] vmpressure: in-kernel notifications

will stay away from converting the actual users, you are all welcome to do so. Signed-off-by: Glauber Costa glom...@openvz.org Signed-off-by: Vladimir Davydov vdavy...@parallels.com Acked-by: Anton Vorontsov an...@enomsg.org Acked-by: Pekka Enberg penb...@kernel.org Reviewed-by: Greg Thelen gthe

Re: [PATCH v14 16/18] vmpressure: in-kernel notifications

One correction: int vmpressure_register_kernel_event(struct cgroup_subsys_state *css, - void (*fn)(void)) +void (*fn)(void *data, int level), void *data) { - struct vmpressure *vmpr = css_to_vmpressure(css); +

Re: [PATCH v14 16/18] vmpressure: in-kernel notifications

On Fri, Dec 20, 2013 at 8:44 PM, Luiz Capitulino lcapitul...@redhat.com wrote: On Fri, 20 Dec 2013 10:03:32 -0500 Luiz Capitulino lcapitul...@redhat.com wrote: The answer for all of your questions above can be summarized by noting that for the lack of other users (at the time), this patch

Re: [PATCH v14 16/18] vmpressure: in-kernel notifications

On Fri, Dec 20, 2013 at 8:53 PM, Luiz Capitulino lcapitul...@redhat.com wrote: On Fri, 20 Dec 2013 20:46:05 +0400 Glauber Costa glom...@gmail.com wrote: On Fri, Dec 20, 2013 at 8:44 PM, Luiz Capitulino lcapitul...@redhat.com wrote: On Fri, 20 Dec 2013 10:03:32 -0500 Luiz Capitulino

Re: [Devel] [PATCH v14 16/18] vmpressure: in-kernel notifications

will stay away from converting the actual users, you are all welcome to do so. Signed-off-by: Glauber Costa glom...@openvz.org Signed-off-by: Vladimir Davydov vdavy...@parallels.com Acked-by: Anton Vorontsov an...@enomsg.org Acked-by: Pekka Enberg penb...@kernel.org Reviewed-by: Greg Thelen gthe

Re: [Devel] [PATCH v14 16/18] vmpressure: in-kernel notifications

One correction: int vmpressure_register_kernel_event(struct cgroup_subsys_state *css, - void (*fn)(void)) +void (*fn)(void *data, int level), void *data) { - struct vmpressure *vmpr = css_to_vmpressure(css); +

Re: [Devel] [PATCH v14 16/18] vmpressure: in-kernel notifications

On Fri, Dec 20, 2013 at 8:44 PM, Luiz Capitulino lcapitul...@redhat.com wrote: On Fri, 20 Dec 2013 10:03:32 -0500 Luiz Capitulino lcapitul...@redhat.com wrote: The answer for all of your questions above can be summarized by noting that for the lack of other users (at the time), this patch

Re: [Devel] [PATCH v14 16/18] vmpressure: in-kernel notifications

On Fri, Dec 20, 2013 at 8:53 PM, Luiz Capitulino lcapitul...@redhat.com wrote: On Fri, 20 Dec 2013 20:46:05 +0400 Glauber Costa glom...@gmail.com wrote: On Fri, Dec 20, 2013 at 8:44 PM, Luiz Capitulino lcapitul...@redhat.com wrote: On Fri, 20 Dec 2013 10:03:32 -0500 Luiz Capitulino

Re: [PATCH 4/6] memcg, slab: check and init memcg_cahes under slab_mutex

On Thu, Dec 19, 2013 at 11:07 AM, Vladimir Davydov wrote: > On 12/18/2013 09:41 PM, Michal Hocko wrote: >> On Wed 18-12-13 17:16:55, Vladimir Davydov wrote: >>> The memcg_params::memcg_caches array can be updated concurrently from >>> memcg_update_cache_size() and memcg_create_kmem_cache().

Re: [PATCH 4/6] memcg, slab: check and init memcg_cahes under slab_mutex

On Thu, Dec 19, 2013 at 11:07 AM, Vladimir Davydov vdavy...@parallels.com wrote: On 12/18/2013 09:41 PM, Michal Hocko wrote: On Wed 18-12-13 17:16:55, Vladimir Davydov wrote: The memcg_params::memcg_caches array can be updated concurrently from memcg_update_cache_size() and

Re: [Devel] [PATCH 4/6] memcg, slab: check and init memcg_cahes under slab_mutex

On Thu, Dec 19, 2013 at 11:07 AM, Vladimir Davydov vdavy...@parallels.com wrote: On 12/18/2013 09:41 PM, Michal Hocko wrote: On Wed 18-12-13 17:16:55, Vladimir Davydov wrote: The memcg_params::memcg_caches array can be updated concurrently from memcg_update_cache_size() and

Re: [Devel] [PATCH] memcg: remove KMEM_ACCOUNTED_ACTIVATED

On Mon, Dec 2, 2013 at 10:15 PM, Michal Hocko mho...@suse.cz wrote: [CCing Glauber - please do so in other posts for kmem related changes] On Mon 02-12-13 17:08:13, Vladimir Davydov wrote: The KMEM_ACCOUNTED_ACTIVATED was introduced by commit a8964b9b (memcg: use static branches when code not

Re: [Devel] [PATCH] memcg: remove KMEM_ACCOUNTED_ACTIVATED

On Mon, Dec 2, 2013 at 10:51 PM, Michal Hocko mho...@suse.cz wrote: On Mon 02-12-13 22:26:48, Glauber Costa wrote: On Mon, Dec 2, 2013 at 10:15 PM, Michal Hocko mho...@suse.cz wrote: [CCing Glauber - please do so in other posts for kmem related changes] On Mon 02-12-13 17:08:13, Vladimir

Re: [Devel] [PATCH] memcg: remove KMEM_ACCOUNTED_ACTIVATED

On Mon, Dec 2, 2013 at 11:21 PM, Vladimir Davydov vdavy...@parallels.com wrote: On 12/02/2013 10:26 PM, Glauber Costa wrote: On Mon, Dec 2, 2013 at 10:15 PM, Michal Hocko mho...@suse.cz wrote: [CCing Glauber - please do so in other posts for kmem related changes] On Mon 02-12-13 17:08:13

Re: [Devel] [PATCH] memcg: remove KMEM_ACCOUNTED_ACTIVATED

Hi, Glauber Hi. In memcg_update_kmem_limit() we do the whole process of limit initialization under a mutex so the situation we need protection from in tcp_update_limit() is impossible. BTW once set, the 'activated' flag is never cleared and never checked alone, only along with the 'active'

Re: [Devel] [PATCH] memcg: remove KMEM_ACCOUNTED_ACTIVATED

Could you do something clever with just one flag? Probably yes. But I doubt it would be that much cleaner, this is just the way that patching sites work. Thank you for spending your time to listen to me. Don't worry! I thank you for carrying this forward. Let me try to explain what is

Re: [Devel] [PATCH v13 00/16] kmemcg shrinkers

Please note that in contrast to previous versions this patch-set implements slab shrinking only when we hit the user memory limit so that kmem allocations will still fail if we are below the user memory limit, but close to the kmem limit. This is, because the implementation of kmem-only

Re: [Devel] [PATCH v13 04/16] memcg: move memcg_caches_array_size() function

On Mon, Dec 9, 2013 at 12:05 PM, Vladimir Davydov vdavy...@parallels.com wrote: I need to move this up a bit, and I am doing in a separate patch just to reduce churn in the patch that needs it. Signed-off-by: Vladimir Davydov vdavy...@parallels.com Reviewed-by: Glauber Costa glom...@openvz.org

Re: [Devel] [PATCH v13 05/16] vmscan: move call to shrink_slab() to shrink_zones()

On Mon, Dec 9, 2013 at 12:05 PM, Vladimir Davydov vdavy...@parallels.com wrote: This reduces the indentation level of do_try_to_free_pages() and removes extra loop over all eligible zones counting the number of on-LRU pages. Looks correct to me. ___

Re: [Devel] [PATCH v13 14/16] vmpressure: in-kernel notifications

On Mon, Dec 9, 2013 at 12:05 PM, Vladimir Davydov vdavy...@parallels.com wrote: From: Glauber Costa glom...@openvz.org During the past weeks, it became clear to us that the shrinker interface It has been more than a few weeks by now =) ___ Devel

Re: [Devel] [PATCH v13 13/16] vmscan: take at least one pass with shrinkers

On Tue, Dec 10, 2013 at 3:50 PM, Vladimir Davydov vdavy...@parallels.com wrote: On 12/10/2013 08:18 AM, Dave Chinner wrote: On Mon, Dec 09, 2013 at 12:05:54PM +0400, Vladimir Davydov wrote: From: Glauber Costa glom...@openvz.org In very low free kernel memory situations, it may be the case

Re: [Devel] Race in memcg kmem?

On Tue, Dec 10, 2013 at 5:59 PM, Vladimir Davydov vdavy...@parallels.com wrote: Hi, Looking through the per-memcg kmem_cache initialization code, I have a bad feeling that it is prone to a race. Before getting to fixing it, I'd like to ensure this race is not only in my imagination. Here it

Re: [Devel] [PATCH v13 11/16] mm: list_lru: add per-memcg lists

OK, as far as I can tell, this is introducing a per-node, per-memcg LRU lists. Is that correct? If so, then that is not what Glauber and I originally intended for memcg LRUs. per-node LRUs are expensive in terms of memory and cross multiplying them by the number of memcgs in a system was not

Re: [Devel] [PATCH 1/2] memcg: fix memcg_size() calculation

On Mon, Dec 16, 2013 at 8:47 PM, Michal Hocko mho...@suse.cz wrote: On Sat 14-12-13 12:15:33, Vladimir Davydov wrote: The mem_cgroup structure contains nr_node_ids pointers to mem_cgroup_per_node objects, not the objects themselves. Ouch! This is 2k per node which is wasted. What a shame I

Re: [PATCH 1/2] memcg: fix memcg_size() calculation

On Mon, Dec 16, 2013 at 8:47 PM, Michal Hocko wrote: > On Sat 14-12-13 12:15:33, Vladimir Davydov wrote: >> The mem_cgroup structure contains nr_node_ids pointers to >> mem_cgroup_per_node objects, not the objects themselves. > > Ouch! This is 2k per node which is wasted. What a shame I haven't >

Re: [PATCH 1/2] memcg: fix memcg_size() calculation

On Mon, Dec 16, 2013 at 8:47 PM, Michal Hocko mho...@suse.cz wrote: On Sat 14-12-13 12:15:33, Vladimir Davydov wrote: The mem_cgroup structure contains nr_node_ids pointers to mem_cgroup_per_node objects, not the objects themselves. Ouch! This is 2k per node which is wasted. What a shame I

Re: [PATCH v13 11/16] mm: list_lru: add per-memcg lists

> OK, as far as I can tell, this is introducing a per-node, per-memcg > LRU lists. Is that correct? > > If so, then that is not what Glauber and I originally intended for > memcg LRUs. per-node LRUs are expensive in terms of memory and cross > multiplying them by the number of memcgs in a system

Re: [PATCH v13 11/16] mm: list_lru: add per-memcg lists

OK, as far as I can tell, this is introducing a per-node, per-memcg LRU lists. Is that correct? If so, then that is not what Glauber and I originally intended for memcg LRUs. per-node LRUs are expensive in terms of memory and cross multiplying them by the number of memcgs in a system was not

Re: Race in memcg kmem?

On Tue, Dec 10, 2013 at 5:59 PM, Vladimir Davydov wrote: > Hi, > > Looking through the per-memcg kmem_cache initialization code, I have a > bad feeling that it is prone to a race. Before getting to fixing it, I'd > like to ensure this race is not only in my imagination. Here it goes. > > We keep

Re: [PATCH v13 13/16] vmscan: take at least one pass with shrinkers

On Tue, Dec 10, 2013 at 3:50 PM, Vladimir Davydov wrote: > On 12/10/2013 08:18 AM, Dave Chinner wrote: >> On Mon, Dec 09, 2013 at 12:05:54PM +0400, Vladimir Davydov wrote: >>> From: Glauber Costa >>> >>> In very low free kernel memory situations, it may be th

Re: [PATCH v13 14/16] vmpressure: in-kernel notifications

On Mon, Dec 9, 2013 at 12:05 PM, Vladimir Davydov wrote: > From: Glauber Costa > > During the past weeks, it became clear to us that the shrinker interface It has been more than a few weeks by now =) -- To unsubscribe from this list: send the line "unsubscribe linux-kerne

Re: [PATCH v13 05/16] vmscan: move call to shrink_slab() to shrink_zones()

On Mon, Dec 9, 2013 at 12:05 PM, Vladimir Davydov wrote: > This reduces the indentation level of do_try_to_free_pages() and removes > extra loop over all eligible zones counting the number of on-LRU pages. > Looks correct to me. -- To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH v13 00/16] kmemcg shrinkers

> Please note that in contrast to previous versions this patch-set implements > slab shrinking only when we hit the user memory limit so that kmem allocations > will still fail if we are below the user memory limit, but close to the kmem > limit. This is, because the implementation of kmem-only

Re: [PATCH v13 04/16] memcg: move memcg_caches_array_size() function

On Mon, Dec 9, 2013 at 12:05 PM, Vladimir Davydov wrote: > I need to move this up a bit, and I am doing in a separate patch just to > reduce churn in the patch that needs it. > > Signed-off-by: Vladimir Davydov Reviewed-by: Glauber Costa -- To unsubscribe from this list: s

Re: Race in memcg kmem?

On Tue, Dec 10, 2013 at 5:59 PM, Vladimir Davydov vdavy...@parallels.com wrote: Hi, Looking through the per-memcg kmem_cache initialization code, I have a bad feeling that it is prone to a race. Before getting to fixing it, I'd like to ensure this race is not only in my imagination. Here it

Re: [PATCH v13 04/16] memcg: move memcg_caches_array_size() function

On Mon, Dec 9, 2013 at 12:05 PM, Vladimir Davydov vdavy...@parallels.com wrote: I need to move this up a bit, and I am doing in a separate patch just to reduce churn in the patch that needs it. Signed-off-by: Vladimir Davydov vdavy...@parallels.com Reviewed-by: Glauber Costa glom...@openvz.org

Re: [PATCH v13 00/16] kmemcg shrinkers

Please note that in contrast to previous versions this patch-set implements slab shrinking only when we hit the user memory limit so that kmem allocations will still fail if we are below the user memory limit, but close to the kmem limit. This is, because the implementation of kmem-only

Re: [PATCH v13 05/16] vmscan: move call to shrink_slab() to shrink_zones()

On Mon, Dec 9, 2013 at 12:05 PM, Vladimir Davydov vdavy...@parallels.com wrote: This reduces the indentation level of do_try_to_free_pages() and removes extra loop over all eligible zones counting the number of on-LRU pages. Looks correct to me. -- To unsubscribe from this list: send the line

Re: [PATCH v13 14/16] vmpressure: in-kernel notifications

On Mon, Dec 9, 2013 at 12:05 PM, Vladimir Davydov vdavy...@parallels.com wrote: From: Glauber Costa glom...@openvz.org During the past weeks, it became clear to us that the shrinker interface It has been more than a few weeks by now =) -- To unsubscribe from this list: send the line

Re: [PATCH v13 13/16] vmscan: take at least one pass with shrinkers

On Tue, Dec 10, 2013 at 3:50 PM, Vladimir Davydov vdavy...@parallels.com wrote: On 12/10/2013 08:18 AM, Dave Chinner wrote: On Mon, Dec 09, 2013 at 12:05:54PM +0400, Vladimir Davydov wrote: From: Glauber Costa glom...@openvz.org In very low free kernel memory situations, it may be the case

Re: [PATCH] memcg: remove KMEM_ACCOUNTED_ACTIVATED

>> >> Could you do something clever with just one flag? Probably yes. But I >> doubt it would >> be that much cleaner, this is just the way that patching sites work. > > Thank you for spending your time to listen to me. > Don't worry! I thank you for carrying this forward. > Let me try to explain

Re: [PATCH] memcg: remove KMEM_ACCOUNTED_ACTIVATED

Could you do something clever with just one flag? Probably yes. But I doubt it would be that much cleaner, this is just the way that patching sites work. Thank you for spending your time to listen to me. Don't worry! I thank you for carrying this forward. Let me try to explain what is

Re: [PATCH] memcg: remove KMEM_ACCOUNTED_ACTIVATED

>>> Hi, Glauber Hi. > > In memcg_update_kmem_limit() we do the whole process of limit > initialization under a mutex so the situation we need protection from in > tcp_update_limit() is impossible. BTW once set, the 'activated' flag is > never cleared and never checked alone, only along with the

Re: [PATCH] memcg: remove KMEM_ACCOUNTED_ACTIVATED

Hi, Glauber Hi. In memcg_update_kmem_limit() we do the whole process of limit initialization under a mutex so the situation we need protection from in tcp_update_limit() is impossible. BTW once set, the 'activated' flag is never cleared and never checked alone, only along with the 'active'

Re: [PATCH] memcg: remove KMEM_ACCOUNTED_ACTIVATED

On Mon, Dec 2, 2013 at 11:21 PM, Vladimir Davydov wrote: > On 12/02/2013 10:26 PM, Glauber Costa wrote: >> >> On Mon, Dec 2, 2013 at 10:15 PM, Michal Hocko wrote: >>> >>> [CCing Glauber - please do so in other posts for kmem related changes] >>> >

Re: [PATCH] memcg: remove KMEM_ACCOUNTED_ACTIVATED

On Mon, Dec 2, 2013 at 10:51 PM, Michal Hocko wrote: > On Mon 02-12-13 22:26:48, Glauber Costa wrote: >> On Mon, Dec 2, 2013 at 10:15 PM, Michal Hocko wrote: >> > [CCing Glauber - please do so in other posts for kmem related changes] >> > >> > On Mon 02-12

Re: [PATCH] memcg: remove KMEM_ACCOUNTED_ACTIVATED

On Mon, Dec 2, 2013 at 10:15 PM, Michal Hocko wrote: > [CCing Glauber - please do so in other posts for kmem related changes] > > On Mon 02-12-13 17:08:13, Vladimir Davydov wrote: >> The KMEM_ACCOUNTED_ACTIVATED was introduced by commit a8964b9b ("memcg: >> use static branches when code not in

Re: [PATCH] memcg: remove KMEM_ACCOUNTED_ACTIVATED

On Mon, Dec 2, 2013 at 10:15 PM, Michal Hocko mho...@suse.cz wrote: [CCing Glauber - please do so in other posts for kmem related changes] On Mon 02-12-13 17:08:13, Vladimir Davydov wrote: The KMEM_ACCOUNTED_ACTIVATED was introduced by commit a8964b9b (memcg: use static branches when code not

Re: [PATCH] memcg: remove KMEM_ACCOUNTED_ACTIVATED

On Mon, Dec 2, 2013 at 10:51 PM, Michal Hocko mho...@suse.cz wrote: On Mon 02-12-13 22:26:48, Glauber Costa wrote: On Mon, Dec 2, 2013 at 10:15 PM, Michal Hocko mho...@suse.cz wrote: [CCing Glauber - please do so in other posts for kmem related changes] On Mon 02-12-13 17:08:13, Vladimir

Re: [PATCH] memcg: remove KMEM_ACCOUNTED_ACTIVATED

On Mon, Dec 2, 2013 at 11:21 PM, Vladimir Davydov vdavy...@parallels.com wrote: On 12/02/2013 10:26 PM, Glauber Costa wrote: On Mon, Dec 2, 2013 at 10:15 PM, Michal Hocko mho...@suse.cz wrote: [CCing Glauber - please do so in other posts for kmem related changes] On Mon 02-12-13 17:08:13

Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92

On Tue, Jul 09, 2013 at 10:50:32AM -0700, Andrew Morton wrote: > On Tue, 9 Jul 2013 21:32:51 +0400 Glauber Costa wrote: > > > > $ dmesg | grep "blocked for more than" > > > [276962.652076] INFO: task xfs-data/sda9:930 blocked for more than 480 > > >

Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92

On Mon, Jul 08, 2013 at 02:53:52PM +0200, Michal Hocko wrote: > On Thu 04-07-13 18:36:43, Michal Hocko wrote: > > On Wed 03-07-13 21:24:03, Dave Chinner wrote: > > > On Tue, Jul 02, 2013 at 02:44:27PM +0200, Michal Hocko wrote: > > > > On Tue 02-07-13 22:19:47, Dave Chinner wrote: > > > > [...] >

Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92

On Mon, Jul 08, 2013 at 02:04:19PM -0700, Andrew Morton wrote: > On Mon, 8 Jul 2013 14:53:52 +0200 Michal Hocko wrote: > > > > Good news! The test was running since morning and it didn't hang nor > > > crashed. So this really looks like the right fix. It will run also > > > during weekend to be

Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92

On Mon, Jul 08, 2013 at 02:04:19PM -0700, Andrew Morton wrote: On Mon, 8 Jul 2013 14:53:52 +0200 Michal Hocko mho...@suse.cz wrote: Good news! The test was running since morning and it didn't hang nor crashed. So this really looks like the right fix. It will run also during weekend to

Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92

On Mon, Jul 08, 2013 at 02:53:52PM +0200, Michal Hocko wrote: On Thu 04-07-13 18:36:43, Michal Hocko wrote: On Wed 03-07-13 21:24:03, Dave Chinner wrote: On Tue, Jul 02, 2013 at 02:44:27PM +0200, Michal Hocko wrote: On Tue 02-07-13 22:19:47, Dave Chinner wrote: [...] Ok, so it's

Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92

On Tue, Jul 09, 2013 at 10:50:32AM -0700, Andrew Morton wrote: On Tue, 9 Jul 2013 21:32:51 +0400 Glauber Costa glom...@gmail.com wrote: $ dmesg | grep blocked for more than [276962.652076] INFO: task xfs-data/sda9:930 blocked for more than 480 seconds. [276962.653097] INFO: task

Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92

On Wed, Jul 03, 2013 at 09:24:03PM +1000, Dave Chinner wrote: > On Tue, Jul 02, 2013 at 02:44:27PM +0200, Michal Hocko wrote: > > On Tue 02-07-13 22:19:47, Dave Chinner wrote: > > [...] > > > Ok, so it's been leaked from a dispose list somehow. Thanks for the > > > info, Michal, it's time to go

Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92

On Wed, Jul 03, 2013 at 09:24:03PM +1000, Dave Chinner wrote: On Tue, Jul 02, 2013 at 02:44:27PM +0200, Michal Hocko wrote: On Tue 02-07-13 22:19:47, Dave Chinner wrote: [...] Ok, so it's been leaked from a dispose list somehow. Thanks for the info, Michal, it's time to go look at the

Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92

On Fri, Jun 28, 2013 at 10:39:43AM +0200, Michal Hocko wrote: > I have just triggered this one. > > [37955.364062] RIP: 0010:[] [] > list_lru_walk_node+0xab/0x140 > [37955.364062] RSP: :8800374af7b8 EFLAGS: 00010286 > [37955.364062] RAX: 0106 RBX: 88002ead7838 RCX: >

Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92

On Fri, Jun 28, 2013 at 10:39:43AM +0200, Michal Hocko wrote: I have just triggered this one. [37955.364062] RIP: 0010:[81127e5b] [81127e5b] list_lru_walk_node+0xab/0x140 [37955.364062] RSP: :8800374af7b8 EFLAGS: 00010286 [37955.364062] RAX: 0106 RBX:

Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92

On Sun, Jun 23, 2013 at 03:51:29PM +0400, Glauber Costa wrote: > On Fri, Jun 21, 2013 at 11:00:21AM +0200, Michal Hocko wrote: > > On Thu 20-06-13 17:12:01, Michal Hocko wrote: > > > I am bisecting it again. It is quite tedious, though, because good case > > > is hard to

Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92

On Fri, Jun 21, 2013 at 11:00:21AM +0200, Michal Hocko wrote: > On Thu 20-06-13 17:12:01, Michal Hocko wrote: > > I am bisecting it again. It is quite tedious, though, because good case > > is hard to be sure about. > > OK, so now I converged to 2d4fc052 (inode: convert inode lru list to generic

Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92

On Fri, Jun 21, 2013 at 11:00:21AM +0200, Michal Hocko wrote: On Thu 20-06-13 17:12:01, Michal Hocko wrote: I am bisecting it again. It is quite tedious, though, because good case is hard to be sure about. OK, so now I converged to 2d4fc052 (inode: convert inode lru list to generic lru

Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92

On Sun, Jun 23, 2013 at 03:51:29PM +0400, Glauber Costa wrote: On Fri, Jun 21, 2013 at 11:00:21AM +0200, Michal Hocko wrote: On Thu 20-06-13 17:12:01, Michal Hocko wrote: I am bisecting it again. It is quite tedious, though, because good case is hard to be sure about. OK, so now I

Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92

On Wed, Jun 19, 2013 at 04:28:01PM +0200, Michal Hocko wrote: > On Wed 19-06-13 09:13:46, Michal Hocko wrote: > > On Tue 18-06-13 10:26:24, Glauber Costa wrote: > > [...] > > > Michal, would you mind testing the following patch? > > > > > > diff --git a/f

Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92

On Wed, Jun 19, 2013 at 04:28:01PM +0200, Michal Hocko wrote: On Wed 19-06-13 09:13:46, Michal Hocko wrote: On Tue 18-06-13 10:26:24, Glauber Costa wrote: [...] Michal, would you mind testing the following patch? diff --git a/fs/inode.c b/fs/inode.c index 00b804e..48eafa6 100644

Re: linux-next: manual merge of the akpm tree with the ext4 tree

On Wed, Jun 19, 2013 at 02:59:17PM -0400, Theodore Ts'o wrote: > On Wed, Jun 19, 2013 at 10:06:35AM -0700, Andrew Morton wrote: > > > > Merge the ext4 change early, please. The core shrinker changes aren't > > 100% certain at this time - first they need to stop oopsing ;) > > Ack, sounds like a

Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92

On Wed, Jun 19, 2013 at 03:57:16PM +0200, Michal Hocko wrote: > On Wed 19-06-13 11:35:27, Glauber Costa wrote: > [...] > > Sorry if you said that before Michal. > > > > But given the backtrace, are you sure this is LRU-related? > > No idea. I just know that my m

Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92

On Wed, Jun 19, 2013 at 11:35:27AM +0400, Glauber Costa wrote: > On Wed, Jun 19, 2013 at 09:13:46AM +0200, Michal Hocko wrote: > > On Tue 18-06-13 10:26:24, Glauber Costa wrote: > > [...] > > > Michal, would you mind testing the following patch? > > > > >

Re: linux-next: manual merge of the akpm tree with the ext4 tree

On Wed, Jun 19, 2013 at 05:27:21PM +1000, Stephen Rothwell wrote: > Hi Andrew, > > Today's linux-next merge of the akpm tree got a conflict in > fs/ext4/extents_status.c between commit 6480bad916be ("ext4: improve > extent cache shrink mechanism to avoid to burn CPU time") from the ext > tree and

Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92

On Wed, Jun 19, 2013 at 09:13:46AM +0200, Michal Hocko wrote: > On Tue 18-06-13 10:26:24, Glauber Costa wrote: > [...] > > Michal, would you mind testing the following patch? > > > > diff --git a/fs/inode.c b/fs/inode.c > > index 00b804e..48eafa6 100644 > > -

Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92

On Wed, Jun 19, 2013 at 09:13:46AM +0200, Michal Hocko wrote: On Tue 18-06-13 10:26:24, Glauber Costa wrote: [...] Michal, would you mind testing the following patch? diff --git a/fs/inode.c b/fs/inode.c index 00b804e..48eafa6 100644 --- a/fs/inode.c +++ b/fs/inode.c @@ -419,6

Re: linux-next: manual merge of the akpm tree with the ext4 tree

On Wed, Jun 19, 2013 at 05:27:21PM +1000, Stephen Rothwell wrote: Hi Andrew, Today's linux-next merge of the akpm tree got a conflict in fs/ext4/extents_status.c between commit 6480bad916be (ext4: improve extent cache shrink mechanism to avoid to burn CPU time) from the ext tree and commit

Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92

On Wed, Jun 19, 2013 at 11:35:27AM +0400, Glauber Costa wrote: On Wed, Jun 19, 2013 at 09:13:46AM +0200, Michal Hocko wrote: On Tue 18-06-13 10:26:24, Glauber Costa wrote: [...] Michal, would you mind testing the following patch? diff --git a/fs/inode.c b/fs/inode.c index 00b804e

Re: linux-next: slab shrinkers: BUG at mm/list_lru.c:92

On Wed, Jun 19, 2013 at 03:57:16PM +0200, Michal Hocko wrote: On Wed 19-06-13 11:35:27, Glauber Costa wrote: [...] Sorry if you said that before Michal. But given the backtrace, are you sure this is LRU-related? No idea. I just know that my mm tree behaves correctly after the whole

  1   2   3   4   5   6   7   8   9   10   >