include/linux/memcontrol.h | 28 ++++------------------ include/linux/mm_inline.h | 2 +- include/linux/vmstat.h | 48 ++------------------------------------ mm/filemap.c | 20 ++++++++-------- mm/huge_memory.c | 4 ++-- mm/khugepaged.c | 8 +++---- mm/memcontrol.c | 20 ++++++++-------- mm/migrate.c | 20 ++++++++-------- mm/page-writeback.c | 2 +- mm/rmap.c | 4 ++-- mm/shmem.c | 6 ++--- mm/vmscan.c | 4 ++-- mm/workingset.c | 2 +- 13 files changed, 53 insertions(+), 115 deletions(-)
The memcg stats are safe against irq (and nmi) context and thus does not require disabling irqs. However for some stats which are also maintained at node level, it is using irq unsafe interface and thus requiring the users to still disables irqs or use interfaces which explicitly disables irqs. Let's move memcg code to use irq safe node level stats function which is already optimized for architectures with HAVE_CMPXCHG_LOCAL (all major ones), so there will not be any performance penalty for its usage. Shakeel Butt (4): memcg: use mod_node_page_state to update stats memcg: remove __mod_lruvec_kmem_state memcg: remove __mod_lruvec_state memcg: remove __lruvec_stat_mod_folio include/linux/memcontrol.h | 28 ++++------------------ include/linux/mm_inline.h | 2 +- include/linux/vmstat.h | 48 ++------------------------------------ mm/filemap.c | 20 ++++++++-------- mm/huge_memory.c | 4 ++-- mm/khugepaged.c | 8 +++---- mm/memcontrol.c | 20 ++++++++-------- mm/migrate.c | 20 ++++++++-------- mm/page-writeback.c | 2 +- mm/rmap.c | 4 ++-- mm/shmem.c | 6 ++--- mm/vmscan.c | 4 ++-- mm/workingset.c | 2 +- 13 files changed, 53 insertions(+), 115 deletions(-) -- 2.47.3
Hi Andrew, can you please pick this series as it is ready for wider testing. thanks, Shakeel On Mon, Nov 10, 2025 at 03:20:04PM -0800, Shakeel Butt wrote: > The memcg stats are safe against irq (and nmi) context and thus does not > require disabling irqs. However for some stats which are also maintained > at node level, it is using irq unsafe interface and thus requiring the > users to still disables irqs or use interfaces which explicitly disables > irqs. Let's move memcg code to use irq safe node level stats function > which is already optimized for architectures with HAVE_CMPXCHG_LOCAL > (all major ones), so there will not be any performance penalty for its > usage. > > Shakeel Butt (4): > memcg: use mod_node_page_state to update stats > memcg: remove __mod_lruvec_kmem_state > memcg: remove __mod_lruvec_state > memcg: remove __lruvec_stat_mod_folio > > include/linux/memcontrol.h | 28 ++++------------------ > include/linux/mm_inline.h | 2 +- > include/linux/vmstat.h | 48 ++------------------------------------ > mm/filemap.c | 20 ++++++++-------- > mm/huge_memory.c | 4 ++-- > mm/khugepaged.c | 8 +++---- > mm/memcontrol.c | 20 ++++++++-------- > mm/migrate.c | 20 ++++++++-------- > mm/page-writeback.c | 2 +- > mm/rmap.c | 4 ++-- > mm/shmem.c | 6 ++--- > mm/vmscan.c | 4 ++-- > mm/workingset.c | 2 +- > 13 files changed, 53 insertions(+), 115 deletions(-) > > -- > 2.47.3 >
Shakeel Butt <shakeel.butt@linux.dev> writes: > The memcg stats are safe against irq (and nmi) context and thus does not > require disabling irqs. However for some stats which are also maintained > at node level, it is using irq unsafe interface and thus requiring the > users to still disables irqs or use interfaces which explicitly disables > irqs. Let's move memcg code to use irq safe node level stats function > which is already optimized for architectures with HAVE_CMPXCHG_LOCAL > (all major ones), so there will not be any performance penalty for its > usage. Do you have any production data for this or it's theory-based? In general I feel we need a benchmark focused on memcg stats: there was a number of performance improvements and regressions in this code over last years, so a dedicated benchmark can help with measuring them. Nice cleanup btw, thanks!
On Tue, Nov 11, 2025 at 11:01:47AM -0800, Roman Gushchin wrote: > Shakeel Butt <shakeel.butt@linux.dev> writes: > > > The memcg stats are safe against irq (and nmi) context and thus does not > > require disabling irqs. However for some stats which are also maintained > > at node level, it is using irq unsafe interface and thus requiring the > > users to still disables irqs or use interfaces which explicitly disables > > irqs. Let's move memcg code to use irq safe node level stats function > > which is already optimized for architectures with HAVE_CMPXCHG_LOCAL > > (all major ones), so there will not be any performance penalty for its > > usage. > > Do you have any production data for this or it's theory-based? At the moment it is theory-based or more specifically based on the comments on HAVE_CMPXCHG_LOCAL variants of stats update functions. > > In general I feel we need a benchmark focused on memcg stats: > there was a number of performance improvements and regressions in this > code over last years, so a dedicated benchmark can help with measuring > them. Yeah it makes sense to have a benchmark. Let me see which benchmark trigger this code paths a lot. At the high level, these interfaces are used in reclaim and migration which are not really that performance critical. I will try benchmarks with a lot of allocs/frees. > > Nice cleanup btw, thanks! Thanks.
On 11/11/25 00:20, Shakeel Butt wrote: > The memcg stats are safe against irq (and nmi) context and thus does not > require disabling irqs. However for some stats which are also maintained > at node level, it is using irq unsafe interface and thus requiring the > users to still disables irqs or use interfaces which explicitly disables > irqs. Let's move memcg code to use irq safe node level stats function > which is already optimized for architectures with HAVE_CMPXCHG_LOCAL > (all major ones), so there will not be any performance penalty for its > usage. > > Shakeel Butt (4): > memcg: use mod_node_page_state to update stats > memcg: remove __mod_lruvec_kmem_state > memcg: remove __mod_lruvec_state > memcg: remove __lruvec_stat_mod_folio Acked-by: Vlastimil Babka <vbabka@suse.cz> > > include/linux/memcontrol.h | 28 ++++------------------ > include/linux/mm_inline.h | 2 +- > include/linux/vmstat.h | 48 ++------------------------------------ > mm/filemap.c | 20 ++++++++-------- > mm/huge_memory.c | 4 ++-- > mm/khugepaged.c | 8 +++---- > mm/memcontrol.c | 20 ++++++++-------- > mm/migrate.c | 20 ++++++++-------- > mm/page-writeback.c | 2 +- > mm/rmap.c | 4 ++-- > mm/shmem.c | 6 ++--- > mm/vmscan.c | 4 ++-- > mm/workingset.c | 2 +- > 13 files changed, 53 insertions(+), 115 deletions(-) >
Hi Shakeel, On 11/11/25 7:20 AM, Shakeel Butt wrote: > The memcg stats are safe against irq (and nmi) context and thus does not > require disabling irqs. However for some stats which are also maintained > at node level, it is using irq unsafe interface and thus requiring the > users to still disables irqs or use interfaces which explicitly disables > irqs. Let's move memcg code to use irq safe node level stats function > which is already optimized for architectures with HAVE_CMPXCHG_LOCAL > (all major ones), so there will not be any performance penalty for its > usage. Generally, places that call __mod_lruvec_state() also call __mod_zone_page_state(), and it also has the corresponding optimized version (mod_zone_page_state()). It seems necessary to clean that up as well, so that those disabling-IRQs that are only used for updating vmstat can be removed. Thanks, Qi > > Shakeel Butt (4): > memcg: use mod_node_page_state to update stats > memcg: remove __mod_lruvec_kmem_state > memcg: remove __mod_lruvec_state > memcg: remove __lruvec_stat_mod_folio > > include/linux/memcontrol.h | 28 ++++------------------ > include/linux/mm_inline.h | 2 +- > include/linux/vmstat.h | 48 ++------------------------------------ > mm/filemap.c | 20 ++++++++-------- > mm/huge_memory.c | 4 ++-- > mm/khugepaged.c | 8 +++---- > mm/memcontrol.c | 20 ++++++++-------- > mm/migrate.c | 20 ++++++++-------- > mm/page-writeback.c | 2 +- > mm/rmap.c | 4 ++-- > mm/shmem.c | 6 ++--- > mm/vmscan.c | 4 ++-- > mm/workingset.c | 2 +- > 13 files changed, 53 insertions(+), 115 deletions(-) >
On Tue, Nov 11, 2025 at 04:36:14PM +0800, Qi Zheng wrote: > Hi Shakeel, > > On 11/11/25 7:20 AM, Shakeel Butt wrote: > > The memcg stats are safe against irq (and nmi) context and thus does not > > require disabling irqs. However for some stats which are also maintained > > at node level, it is using irq unsafe interface and thus requiring the > > users to still disables irqs or use interfaces which explicitly disables > > irqs. Let's move memcg code to use irq safe node level stats function > > which is already optimized for architectures with HAVE_CMPXCHG_LOCAL > > (all major ones), so there will not be any performance penalty for its > > usage. > > Generally, places that call __mod_lruvec_state() also call > __mod_zone_page_state(), and it also has the corresponding optimized > version (mod_zone_page_state()). It seems necessary to clean that up > as well, so that those disabling-IRQs that are only used for updating > vmstat can be removed. I agree, please take a stab at that.
On 11/12/25 12:45 AM, Shakeel Butt wrote: > On Tue, Nov 11, 2025 at 04:36:14PM +0800, Qi Zheng wrote: >> Hi Shakeel, >> >> On 11/11/25 7:20 AM, Shakeel Butt wrote: >>> The memcg stats are safe against irq (and nmi) context and thus does not >>> require disabling irqs. However for some stats which are also maintained >>> at node level, it is using irq unsafe interface and thus requiring the >>> users to still disables irqs or use interfaces which explicitly disables >>> irqs. Let's move memcg code to use irq safe node level stats function >>> which is already optimized for architectures with HAVE_CMPXCHG_LOCAL >>> (all major ones), so there will not be any performance penalty for its >>> usage. >> >> Generally, places that call __mod_lruvec_state() also call >> __mod_zone_page_state(), and it also has the corresponding optimized >> version (mod_zone_page_state()). It seems necessary to clean that up >> as well, so that those disabling-IRQs that are only used for updating >> vmstat can be removed. > > I agree, please take a stab at that. OK, will do.
On Mon, Nov 10, 2025 at 03:20:04PM -0800, Shakeel Butt wrote: > The memcg stats are safe against irq (and nmi) context and thus does not > require disabling irqs. However for some stats which are also maintained > at node level, it is using irq unsafe interface and thus requiring the > users to still disables irqs or use interfaces which explicitly disables > irqs. Let's move memcg code to use irq safe node level stats function > which is already optimized for architectures with HAVE_CMPXCHG_LOCAL > (all major ones), so there will not be any performance penalty for its > usage. Are you or Qi planning a follow-up that converts spin_lock_irq() to spin_lock() in places where they disabled IRQs was just to update vmstat? Qi's zombie memcg series will depends on that work I guess.. -- Cheers, Harry / Hyeonggon > Shakeel Butt (4): > memcg: use mod_node_page_state to update stats > memcg: remove __mod_lruvec_kmem_state > memcg: remove __mod_lruvec_state > memcg: remove __lruvec_stat_mod_folio > > include/linux/memcontrol.h | 28 ++++------------------ > include/linux/mm_inline.h | 2 +- > include/linux/vmstat.h | 48 ++------------------------------------ > mm/filemap.c | 20 ++++++++-------- > mm/huge_memory.c | 4 ++-- > mm/khugepaged.c | 8 +++---- > mm/memcontrol.c | 20 ++++++++-------- > mm/migrate.c | 20 ++++++++-------- > mm/page-writeback.c | 2 +- > mm/rmap.c | 4 ++-- > mm/shmem.c | 6 ++--- > mm/vmscan.c | 4 ++-- > mm/workingset.c | 2 +- > 13 files changed, 53 insertions(+), 115 deletions(-) > > -- > 2.47.3 >
Hi, On 11/11/25 8:59 AM, Harry Yoo wrote: > On Mon, Nov 10, 2025 at 03:20:04PM -0800, Shakeel Butt wrote: >> The memcg stats are safe against irq (and nmi) context and thus does not >> require disabling irqs. However for some stats which are also maintained >> at node level, it is using irq unsafe interface and thus requiring the >> users to still disables irqs or use interfaces which explicitly disables >> irqs. Let's move memcg code to use irq safe node level stats function >> which is already optimized for architectures with HAVE_CMPXCHG_LOCAL >> (all major ones), so there will not be any performance penalty for its >> usage. Good job. Thanks! > > Are you or Qi planning a follow-up that converts spin_lock_irq() to > spin_lock() in places where they disabled IRQs was just to update vmstat? Perhaps this change could be implemented together in [PATCH 1/4]? Of course, it's also reasonable to make it a separate patch. If we choose this method, I’m fine with either me or Shakeel doing it. > > Qi's zombie memcg series will depends on that work I guess.. Yes, and there are other places that also need to be converted, such as __folio_migrate_mapping(). Thanks, Qi >
On Tue, Nov 11, 2025 at 10:23:15AM +0800, Qi Zheng wrote: > Hi, > [...] > > > > Are you or Qi planning a follow-up that converts spin_lock_irq() to > > spin_lock() in places where they disabled IRQs was just to update vmstat? > > Perhaps this change could be implemented together in [PATCH 1/4]? > > Of course, it's also reasonable to make it a separate patch. If we > choose this method, I’m fine with either me or Shakeel doing it. > Let's do it separately as I wanted to keep the memcg related changes self-contained. Qi, can you please take a stab at that? > > > > Qi's zombie memcg series will depends on that work I guess.. > > Yes, and there are other places that also need to be converted, such as > __folio_migrate_mapping(). I see __mod_zone_page_state() usage in __folio_migrate_mapping() and using the same reasoning we can convert it to use mod_zone_page_state(). Where else do you need to do these conversions (other than __folio_migrate_mapping)?
Hi Shakeel, On 11/11/25 10:39 AM, Shakeel Butt wrote: > On Tue, Nov 11, 2025 at 10:23:15AM +0800, Qi Zheng wrote: >> Hi, >> > [...] >>> >>> Are you or Qi planning a follow-up that converts spin_lock_irq() to >>> spin_lock() in places where they disabled IRQs was just to update vmstat? >> >> Perhaps this change could be implemented together in [PATCH 1/4]? >> >> Of course, it's also reasonable to make it a separate patch. If we >> choose this method, I’m fine with either me or Shakeel doing it. >> > > Let's do it separately as I wanted to keep the memcg related changes > self-contained. OK. > > Qi, can you please take a stab at that? Sure, I will do it. > >>> >>> Qi's zombie memcg series will depends on that work I guess.. >> >> Yes, and there are other places that also need to be converted, such as >> __folio_migrate_mapping(). > > I see __mod_zone_page_state() usage in __folio_migrate_mapping() and > using the same reasoning we can convert it to use mod_zone_page_state(). > Where else do you need to do these conversions (other than > __folio_migrate_mapping)? I mean converting these places to use spin_lock() instead of spin_lock_irq(). Thanks, Qi
On Tue, Nov 11, 2025 at 10:48:18AM +0800, Qi Zheng wrote: > Hi Shakeel, > > On 11/11/25 10:39 AM, Shakeel Butt wrote: > > On Tue, Nov 11, 2025 at 10:23:15AM +0800, Qi Zheng wrote: > > > Hi, > > > > > [...] > > > > > > > > Are you or Qi planning a follow-up that converts spin_lock_irq() to > > > > spin_lock() in places where they disabled IRQs was just to update vmstat? > > > > > > Perhaps this change could be implemented together in [PATCH 1/4]? > > > > > > Of course, it's also reasonable to make it a separate patch. If we > > > choose this method, I’m fine with either me or Shakeel doing it. > > > > > > > Let's do it separately as I wanted to keep the memcg related changes > > self-contained. > > OK. Agreed. > > Qi, can you please take a stab at that? > > Sure, I will do it. I'll be more than happy to review that ;) > > > > Qi's zombie memcg series will depends on that work I guess.. > > > > > > Yes, and there are other places that also need to be converted, such as > > > __folio_migrate_mapping(). > > > > I see __mod_zone_page_state() usage in __folio_migrate_mapping() and > > using the same reasoning we can convert it to use mod_zone_page_state(). > > Where else do you need to do these conversions (other than > > __folio_migrate_mapping)? > > I mean converting these places to use spin_lock() instead of > spin_lock_irq(). Just one thing I noticed while looking at __folio_migrate_mapping()... - xas_lock_irq() -> xas_unlock() -> local_irq_enable() - swap_cluster_get_and_lock_irq() -> swap_cluster_unlock() -> local_irq_enable() is wrong because spin_lock_irq() doesn't disable IRQ on PREEMPT_RT. Not 100% sure if it would be benign or lead to actual bugs that need to be fixed in -stable kernels. Cc'ing RT folks again :) -- Cheers, Harry / Hyeonggon
> > I mean converting these places to use spin_lock() instead of > > spin_lock_irq(). > > Just one thing I noticed while looking at __folio_migrate_mapping()... > > - xas_lock_irq() -> xas_unlock() -> local_irq_enable() > - swap_cluster_get_and_lock_irq() -> swap_cluster_unlock() -> local_irq_enable() > > is wrong because spin_lock_irq() doesn't disable IRQ on PREEMPT_RT. > > Not 100% sure if it would be benign or lead to actual bugs that need > to be fixed in -stable kernels. > > Cc'ing RT folks again :) The tail in __folio_migrate_mapping() after xas_unlock()/ swap_cluster_unlock(), is limited to __mod_lruvec_state() based stats updates. There is a preempt_disable_nested() in __mod_zone_page_state() to ensure that the update happens on the same CPU and is not preempted. On PREEMPT_RT there should be no in-IRQ updates of these counters. The IRQ enable at the end does nothing. There might be CPU migration between the individual stats updates. If it remains like this, it is fine. Please don't advertise ;) Sebastian
On Tue, Nov 11, 2025 at 10:48:18AM +0800, Qi Zheng wrote: > Hi Shakeel, > > On 11/11/25 10:39 AM, Shakeel Butt wrote: > > On Tue, Nov 11, 2025 at 10:23:15AM +0800, Qi Zheng wrote: > > > Hi, > > > > > [...] > > > > > > > > Are you or Qi planning a follow-up that converts spin_lock_irq() to > > > > spin_lock() in places where they disabled IRQs was just to update vmstat? > > > > > > Perhaps this change could be implemented together in [PATCH 1/4]? > > > > > > Of course, it's also reasonable to make it a separate patch. If we > > > choose this method, I’m fine with either me or Shakeel doing it. > > > > > > > Let's do it separately as I wanted to keep the memcg related changes > > self-contained. > > OK. > > > > > Qi, can you please take a stab at that? > > Sure, I will do it. > > > > > > > > > > > Qi's zombie memcg series will depends on that work I guess.. > > > > > > Yes, and there are other places that also need to be converted, such as > > > __folio_migrate_mapping(). > > > > I see __mod_zone_page_state() usage in __folio_migrate_mapping() and > > using the same reasoning we can convert it to use mod_zone_page_state(). > > Where else do you need to do these conversions (other than > > __folio_migrate_mapping)? > > I mean converting these places to use spin_lock() instead of > spin_lock_irq(). For only stats, right?
On 11/11/25 11:00 AM, Shakeel Butt wrote: > On Tue, Nov 11, 2025 at 10:48:18AM +0800, Qi Zheng wrote: >> Hi Shakeel, >> >> On 11/11/25 10:39 AM, Shakeel Butt wrote: >>> On Tue, Nov 11, 2025 at 10:23:15AM +0800, Qi Zheng wrote: >>>> Hi, >>>> >>> [...] >>>>> >>>>> Are you or Qi planning a follow-up that converts spin_lock_irq() to >>>>> spin_lock() in places where they disabled IRQs was just to update vmstat? >>>> >>>> Perhaps this change could be implemented together in [PATCH 1/4]? >>>> >>>> Of course, it's also reasonable to make it a separate patch. If we >>>> choose this method, I’m fine with either me or Shakeel doing it. >>>> >>> >>> Let's do it separately as I wanted to keep the memcg related changes >>> self-contained. >> >> OK. >> >>> >>> Qi, can you please take a stab at that? >> >> Sure, I will do it. >> >>> >>>>> >>>>> Qi's zombie memcg series will depends on that work I guess.. >>>> >>>> Yes, and there are other places that also need to be converted, such as >>>> __folio_migrate_mapping(). >>> >>> I see __mod_zone_page_state() usage in __folio_migrate_mapping() and >>> using the same reasoning we can convert it to use mod_zone_page_state(). >>> Where else do you need to do these conversions (other than >>> __folio_migrate_mapping)? >> >> I mean converting these places to use spin_lock() instead of >> spin_lock_irq(). > > For only stats, right? Right, for thoes places where they disabled IRQs was just to update vmstat.
On Tue, Nov 11, 2025 at 11:07:09AM +0800, Qi Zheng wrote: > > > On 11/11/25 11:00 AM, Shakeel Butt wrote: > > On Tue, Nov 11, 2025 at 10:48:18AM +0800, Qi Zheng wrote: > > > Hi Shakeel, > > > > > > On 11/11/25 10:39 AM, Shakeel Butt wrote: > > > > On Tue, Nov 11, 2025 at 10:23:15AM +0800, Qi Zheng wrote: > > > > > Hi, > > > > > > > > > [...] > > > > > > > > > > > > Are you or Qi planning a follow-up that converts spin_lock_irq() to > > > > > > spin_lock() in places where they disabled IRQs was just to update vmstat? > > > > > > > > > > Perhaps this change could be implemented together in [PATCH 1/4]? > > > > > > > > > > Of course, it's also reasonable to make it a separate patch. If we > > > > > choose this method, I’m fine with either me or Shakeel doing it. > > > > > > > > > > > > > Let's do it separately as I wanted to keep the memcg related changes > > > > self-contained. > > > > > > OK. > > > > > > > > > > > Qi, can you please take a stab at that? > > > > > > Sure, I will do it. > > > > > > > > > > > > > > > > > > > Qi's zombie memcg series will depends on that work I guess.. > > > > > > > > > > Yes, and there are other places that also need to be converted, such as > > > > > __folio_migrate_mapping(). > > > > > > > > I see __mod_zone_page_state() usage in __folio_migrate_mapping() and > > > > using the same reasoning we can convert it to use mod_zone_page_state(). > > > > Where else do you need to do these conversions (other than > > > > __folio_migrate_mapping)? > > > > > > I mean converting these places to use spin_lock() instead of > > > spin_lock_irq(). > > > > For only stats, right? > > Right, for thoes places where they disabled IRQs was just to update > vmstat. ...Or if they disabled IRQs for other reasons as well, we can still move vmstat update code outside the IRQ disabled region. -- Cheers, Harry / Hyeonggon
On 11/11/25 11:18 AM, Harry Yoo wrote: > On Tue, Nov 11, 2025 at 11:07:09AM +0800, Qi Zheng wrote: >> >> >> On 11/11/25 11:00 AM, Shakeel Butt wrote: >>> On Tue, Nov 11, 2025 at 10:48:18AM +0800, Qi Zheng wrote: >>>> Hi Shakeel, >>>> >>>> On 11/11/25 10:39 AM, Shakeel Butt wrote: >>>>> On Tue, Nov 11, 2025 at 10:23:15AM +0800, Qi Zheng wrote: >>>>>> Hi, >>>>>> >>>>> [...] >>>>>>> >>>>>>> Are you or Qi planning a follow-up that converts spin_lock_irq() to >>>>>>> spin_lock() in places where they disabled IRQs was just to update vmstat? >>>>>> >>>>>> Perhaps this change could be implemented together in [PATCH 1/4]? >>>>>> >>>>>> Of course, it's also reasonable to make it a separate patch. If we >>>>>> choose this method, I’m fine with either me or Shakeel doing it. >>>>>> >>>>> >>>>> Let's do it separately as I wanted to keep the memcg related changes >>>>> self-contained. >>>> >>>> OK. >>>> >>>>> >>>>> Qi, can you please take a stab at that? >>>> >>>> Sure, I will do it. >>>> >>>>> >>>>>>> >>>>>>> Qi's zombie memcg series will depends on that work I guess.. >>>>>> >>>>>> Yes, and there are other places that also need to be converted, such as >>>>>> __folio_migrate_mapping(). >>>>> >>>>> I see __mod_zone_page_state() usage in __folio_migrate_mapping() and >>>>> using the same reasoning we can convert it to use mod_zone_page_state(). >>>>> Where else do you need to do these conversions (other than >>>>> __folio_migrate_mapping)? >>>> >>>> I mean converting these places to use spin_lock() instead of >>>> spin_lock_irq(). >>> >>> For only stats, right? >> >> Right, for thoes places where they disabled IRQs was just to update >> vmstat. > > ...Or if they disabled IRQs for other reasons as well, we can still move > vmstat update code outside the IRQ disabled region. Ok, I will take a closer look. >
© 2016 - 2026 Red Hat, Inc.