From: "Paul E. McKenney"
This commit retrospectively prepares for testing of RCU readers invoked
from hardware interrupt handlers (for example, HRTIMER_MODE_HARD hrtimer
handlers) in kernels built with CONFIG_RCU_TORTURE_TEST_CHK_RDR_STATE=y,
which is rarely used but sometimes extremely useful.
Add a call to dev_dstats_rx_dropped_add() in nsim_queue_free() to
account for the number of packets dropped when purging the skb queue.
This improves the accuracy of RX drop statistics reported by netdevsim.
local_bh_{disable, enable}() protection is used to disable preemption,
which is necessary
On Tue, 17 Jun 2025 06:24:23 -0700 Breno Leitao wrote:
> > here we are in process context and debug checks complain about the use
> > of this_cpu_ptr(). Let's wrap this in local_bh_disable() / enable() ?
>
> Thanks. I was able to reproduce it. Your suggestion avoids the complain.
> I suppose we
On Tue, Jun 17, 2025 at 05:59:34AM -0700, Jakub Kicinski wrote:
> On Tue, 17 Jun 2025 01:19:00 -0700 Breno Leitao wrote:
> > -static void nsim_queue_free(struct nsim_rq *rq)
> > +static void nsim_queue_free(struct net_device *dev, struct nsim_rq *rq)
> > {
> > hrtimer_cancel(&rq->napi_timer);
On Tue, 17 Jun 2025 01:19:00 -0700 Breno Leitao wrote:
> -static void nsim_queue_free(struct nsim_rq *rq)
> +static void nsim_queue_free(struct net_device *dev, struct nsim_rq *rq)
> {
> hrtimer_cancel(&rq->napi_timer);
> + dev_dstats_rx_dropped_add(dev, rq->skb_queue.qlen);
here we are
Add a call to dev_dstats_rx_dropped_add() in nsim_queue_free() to
account for the number of packets dropped when purging the skb queue.
This improves the accuracy of RX drop statistics reported by
netdevsim.
Suggested-by: Jakub Kicinski
Signed-off-by: Breno Leitao
---
drivers/net/netdevsim
On Fri, Jun 13, 2025 at 07:55:07AM -0700, Jakub Kicinski wrote:
> On Fri, 13 Jun 2025 07:47:11 -0700 Breno Leitao wrote:
> > > static void nsim_queue_free(struct nsim_rq *rq)
> > > {
> > > + struct net_device *dev = rq->napi.dev;
> > > +
> > > hrtimer_cancel(&rq->napi_timer);
> > > + dev_dstats
On Fri, 13 Jun 2025 07:47:11 -0700 Breno Leitao wrote:
> > static void nsim_queue_free(struct nsim_rq *rq)
> > {
> > + struct net_device *dev = rq->napi.dev;
> > +
> > hrtimer_cancel(&rq->napi_timer);
> > + dev_dstats_rx_dropped_add(dev, rq->skb_queue.qlen);
>
> This is wrong and it wi
On Fri, Jun 13, 2025 at 03:40:01AM -0700, Breno Leitao wrote:
> Add a call to dev_dstats_rx_dropped_add() in nsim_queue_free() to
> account for the number of packets dropped when purging the skb queue.
>
> This improves the accuracy of RX drop statistics reported by
> netdevsim.
&g
Add a call to dev_dstats_rx_dropped_add() in nsim_queue_free() to
account for the number of packets dropped when purging the skb queue.
This improves the accuracy of RX drop statistics reported by
netdevsim.
Suggested-by: Jakub Kicinski
Signed-off-by: Breno Leitao
---
drivers/net/netdevsim
On 5/2/25 16:12, Peter Zijlstra wrote:
> Sean noted that scripts/Makefile.lib:name-fix-token rule will mangle
> the module name with s/-/_/g.
>
> Since this happens late in the build, only the kernel needs to bother
> with this, the modpost tool still sees the original name.
>
> Reported-by: Sean
Sean noted that scripts/Makefile.lib:name-fix-token rule will mangle
the module name with s/-/_/g.
Since this happens late in the build, only the kernel needs to bother
with this, the modpost tool still sees the original name.
Reported-by: Sean Christopherson
Signed-off-by: Peter Zijlstra (Intel
On Mon, Dec 02, 2024 at 03:59:52PM +0100, Peter Zijlstra wrote:
> Sean noted that scripts/Makefile.lib:name-fix-token rule will mangle
> the module name with s/-/_/g.
>
> Since this happens late in the build, only the kernel needs to bother
> with this, the modpost tool still sees the original nam
On Wed, Nov 27, 2024 at 05:33:32PM -0800, Sean Christopherson wrote:
>Drop x86.c's local pre-computed cr4_reserved bits and instead fold KVM's
>reserved bits into the guest's reserved bits. This fixes a bug where VMX's
>set_cr4_guest_host_mask() fails to accou
On Mon, Dec 02, 2024, Peter Zijlstra wrote:
> Sean noted that scripts/Makefile.lib:name-fix-token rule will mangle
> the module name with s/-/_/g.
>
> Since this happens late in the build, only the kernel needs to bother
> with this, the modpost tool still sees the original name.
>
> Reported-by:
Sean noted that scripts/Makefile.lib:name-fix-token rule will mangle
the module name with s/-/_/g.
Since this happens late in the build, only the kernel needs to bother
with this, the modpost tool still sees the original name.
Reported-by: Sean Christopherson
Signed-off-by: Peter Zijlstra (Intel
Explicitly zero out the feature word in kvm_cpu_caps if the word's
associated CPUID function is greater than the max leaf supported by the
CPU. For such unsupported functions, Intel CPUs return the output from
the last supported leaf, not all zeros.
Practically speaking, this is likely a benign b
Drop x86.c's local pre-computed cr4_reserved bits and instead fold KVM's
reserved bits into the guest's reserved bits. This fixes a bug where VMX's
set_cr4_guest_host_mask() fails to account for KVM-reserved bits when
deciding which bits can be passed through to the guest. In
So far, we have relied on the fact that gcc supports both
-mprofile-kernel, as well as -fpatchable-function-entry, and clang
supports neither. Our Makefile only checks for CONFIG_MPROFILE_KERNEL to
decide which files to build. Clang has a feature request out [*] to
implement -fpatchable-function-en
w bpf_prog_pack, while it could do with PMD_SIZE'ed packs.
> >
> > Don't account for number of nodes for VM_ALLOW_HUGE_VMAP with
> > NUMA_NO_NODE and use huge pages whenever the requested allocation size
> > is larger than PMD_SIZE.
>
> Patch looks ok but messag
ed memory is not distributed between nodes and
> there is no advantage in such approach.
> On the contrary, BPF allocates PMD_SIZE * num_possible_nodes() for each
> new bpf_prog_pack, while it could do with PMD_SIZE'ed packs.
>
> Don't account for number of nodes for VM_A
ch.
On the contrary, BPF allocates PMD_SIZE * num_possible_nodes() for each
new bpf_prog_pack, while it could do with PMD_SIZE'ed packs.
Don't account for number of nodes for VM_ALLOW_HUGE_VMAP with
NUMA_NO_NODE and use huge pages whenever the requested allocation size
is larger than PMD_
On Tue, 26 Dec 2023, Pasha Tatashin wrote:
> iommu allocations should be accounted in order to allow admins to
> monitor and limit the amount of iommu memory.
>
> Signed-off-by: Pasha Tatashin
> Acked-by: Michael S. Tsirkin
Acked-by: David Rientjes
iommu allocations should be accounted in order to allow admins to
monitor and limit the amount of iommu memory.
Signed-off-by: Pasha Tatashin
Acked-by: Michael S. Tsirkin
---
drivers/vhost/vdpa.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Changelog:
v1:
This patch is spinned of f
unsigned long cur_delta, base_energy;
@@ -7962,18 +7971,17 @@ static int find_energy_efficient_cpu(struct task_struct
*p, int prev_cpu)
if (cpumask_empty(cpus))
continue;
- /* Account thermal pressure for the energy estimation
unsigned long rq_util_min, rq_util_max;
unsigned long cur_delta, base_energy;
@@ -7962,18 +7969,17 @@ static int find_energy_efficient_cpu(struct task_struct
*p, int prev_cpu)
if (cpumask_empty(cpus))
continue;
- /* Account ther
ergy;
@@ -7962,18 +7969,17 @@ static int find_energy_efficient_cpu(struct task_struct
*p, int prev_cpu)
if (cpumask_empty(cpus))
continue;
- /* Account thermal pressure for the energy estimation */
+ /* Account external press
iommu allocations should be accounted in order to allow admins to
monitor and limit the amount of iommu memory.
Signed-off-by: Pasha Tatashin
---
drivers/vhost/vdpa.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
This patch is spinned of from the series:
https://lore.kernel.org/all/20
On Thu, Apr 15, 2021, Wanpeng Li wrote:
> On Thu, 15 Apr 2021 at 08:49, Sean Christopherson wrote:
> >
> > On Wed, Apr 14, 2021, Wanpeng Li wrote:
> > > On Wed, 14 Apr 2021 at 01:25, Sean Christopherson
> > > wrote:
> > > >
> > > > On Tue, Apr 13, 2021, Wanpeng Li wrote:
> > > > > The bugzilla h
On Thu, 15 Apr 2021 at 08:49, Sean Christopherson wrote:
>
> On Wed, Apr 14, 2021, Wanpeng Li wrote:
> > On Wed, 14 Apr 2021 at 01:25, Sean Christopherson wrote:
> > >
> > > On Tue, Apr 13, 2021, Wanpeng Li wrote:
> > > > The bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=209831
> > > > rep
On Wed, Apr 14, 2021, Wanpeng Li wrote:
> On Wed, 14 Apr 2021 at 01:25, Sean Christopherson wrote:
> >
> > On Tue, Apr 13, 2021, Wanpeng Li wrote:
> > > The bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=209831
> > > reported that the guest time remains 0 when running a while true
> > > loop
On Wed, 14 Apr 2021 at 01:25, Sean Christopherson wrote:
>
> On Tue, Apr 13, 2021, Wanpeng Li wrote:
> > The bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=209831
> > reported that the guest time remains 0 when running a while true
> > loop in the guest.
> >
> > The commit 87fa7f3e98a131 ("x
Now both base page and THP NUMA migration is done via migrate_misplaced_page(),
keep the counters correctly for THP.
Signed-off-by: Yang Shi
---
mm/migrate.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/mm/migrate.c b/mm/migrate.c
index 333448aa53f1..a473f25fbd01 10
On Tue, Apr 13, 2021, Wanpeng Li wrote:
> The bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=209831
> reported that the guest time remains 0 when running a while true
> loop in the guest.
>
> The commit 87fa7f3e98a131 ("x86/kvm: Move context tracking where it
> belongs") moves guest_exit_irq
On 13.04.21 09:16, Wanpeng Li wrote:
The bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=209831
reported that the guest time remains 0 when running a while true
loop in the guest.
The commit 87fa7f3e98a131 ("x86/kvm: Move context tracking where it
belongs") moves guest_exit_irqoff() clos
The bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=209831
reported that the guest time remains 0 when running a while true
loop in the guest.
The commit 87fa7f3e98a131 ("x86/kvm: Move context tracking where it
belongs") moves guest_exit_irqoff() close to vmexit breaks the
tick-based time acc
Allow page counters to be more readily modified by callers which have
a folio. Name these wrappers with 'stat' instead of 'state' as requested
by Linus here:
https://lore.kernel.org/linux-mm/CAHk-=wj847sudr-kt+46ft3+xffgiwpgthvm7djwgdi4cvr...@mail.gmail.com/
Signed-off-by: Matthew Wilcox (Oracle)
as to avoid
> mishandling negative "sleep length" values (patch [4/5]).
>
> Finally, make the menu governor take negative "sleep length" values into
> account properly (patch [5/5]).
>
> Please see the changelogs of the patches for details.
Given no objections or concerns regarding this lot, let me queue it up.
Thanks!
Hi,
On 3/31/21 12:08 AM, Srinivas Pandruvada wrote:
> In some cases when firmware is busy or updating, some mailbox commands
> still timeout on some newer CPUs. To fix this issue, change how we
> process timeout.
>
> With this change, replaced timeout from using simple count with real
> timeout i
On Tue, Mar 30, 2021, Wanpeng Li wrote:
> On Tue, 30 Mar 2021 at 01:15, Sean Christopherson wrote:
> >
> > +Thomas
> >
> > On Mon, Mar 29, 2021, Wanpeng Li wrote:
> > > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> > > index 32cf828..85695b3 100644
> > > --- a/arch/x86/kvm/vmx/vmx
On Wed, Mar 31, 2021 at 07:47:04PM +0100, Matthew Wilcox (Oracle) wrote:
> Allow page counters to be more readily modified by callers which have
> a folio. Name these wrappers with 'stat' instead of 'state' as requested
> by Linus here:
Looks good,
Reviewed-by: Christoph Hellwig
For each memory cgroup, account its usage of the
top tier memory at the time a top tier page is assigned and
uncharged from the cgroup.
Signed-off-by: Tim Chen
---
include/linux/memcontrol.h | 1 +
mm/memcontrol.c| 39 +-
2 files changed, 39
Track the global top tier memory usage stats. They are used as the basis of
deciding when to start demoting pages from memory cgroups that have exceeded
their soft limit. We start reclaiming top tier memory when the total
top tier memory is low.
Signed-off-by: Tim Chen
---
include/linux/vmstat.
+
+ /* Keep bimc gfx clock port on all the time */
+ clk_prepare_enable(gcc_bimc_gfx_clk.clkr.hw.clk);
+
>>> Preferably just set these various bits with regmap_update_bits() during
>>> probe. Also, please do it before regsitering the clks, not after.
>> To be fair,
Quoting Konrad Dybcio (2021-02-25 11:09:14)
> Hi and sorry for the late reply,
>
I'm sorry too. This fell off my review queue for some time.
>
> >> +
> >> + /* Keep bimc gfx clock port on all the time */
> >> + clk_prepare_enable(gcc_bimc_gfx_clk.clkr.hw.clk);
> >> +
> > Preferably
Allow page counters to be more readily modified by callers which have
a folio. Name these wrappers with 'stat' instead of 'state' as requested
by Linus here:
https://lore.kernel.org/linux-mm/CAHk-=wj847sudr-kt+46ft3+xffgiwpgthvm7djwgdi4cvr...@mail.gmail.com/
Signed-off-by: Matthew Wilcox (Oracle)
On 31/03/21 04:30, Sean Christopherson wrote:
Switch to GFP_KERNEL_ACCOUNT for a handful of allocations that are
clearly associated with a single task/VM.
Note, there are a several SEV allocations that aren't accounted, but
those can (hopefully) be fixed by using the local stack for memory.
Sig
On Wed, 31 Mar 2021 at 11:24, Sean Christopherson wrote:
>
> On Wed, Mar 31, 2021, Wanpeng Li wrote:
> > On Wed, 31 Mar 2021 at 10:32, Sean Christopherson wrote:
> > >
> > > Use GFP_KERNEL_ACCOUNT for the vCPU allocations, the vCPUs are very much
> > > tied to a single task/VM. For x86, the allo
On Wed, Mar 31, 2021, Wanpeng Li wrote:
> On Wed, 31 Mar 2021 at 10:32, Sean Christopherson wrote:
> >
> > Use GFP_KERNEL_ACCOUNT for the vCPU allocations, the vCPUs are very much
> > tied to a single task/VM. For x86, the allocations were accounted up
> > until the allocation code was moved to c
On Wed, 31 Mar 2021 at 10:32, Sean Christopherson wrote:
>
> Use GFP_KERNEL_ACCOUNT for the vCPU allocations, the vCPUs are very much
> tied to a single task/VM. For x86, the allocations were accounted up
> until the allocation code was moved to common KVM. For all other
> architectures, vCPU al
Switch to GFP_KERNEL_ACCOUNT for a handful of allocations that are
clearly associated with a single task/VM.
Note, there are a several SEV allocations that aren't accounted, but
those can (hopefully) be fixed by using the local stack for memory.
Signed-off-by: Sean Christopherson
---
arch/x86/k
Use GFP_KERNEL_ACCOUNT for the vCPU allocations, the vCPUs are very much
tied to a single task/VM. For x86, the allocations were accounted up
until the allocation code was moved to common KVM. For all other
architectures, vCPU allocations were never previously accounted, but only
because most arc
In some cases when firmware is busy or updating, some mailbox commands
still timeout on some newer CPUs. To fix this issue, change how we
process timeout.
With this change, replaced timeout from using simple count with real
timeout in micro-seconds using ktime. When the command response takes
more
On Tue, Mar 30, 2021 at 4:00 AM Zhou Ti (x2019cwm) wrote:
>
> On Mon 2021-03-29 14:37 Rafael J. Wysocki wrote:
> > Make the menu governor check the tick_nohz_get_next_hrtimer()
> > return value so as to avoid dealing with negative "sleep length"
> > values and make it use that value directly when
On Mon 2021-03-29 14:37 Rafael J. Wysocki wrote:
> Make the menu governor check the tick_nohz_get_next_hrtimer()
> return value so as to avoid dealing with negative "sleep length"
> values and make it use that value directly when the tick is stopped.
>
> While at it, rename local variable delta_ne
On Tue, 30 Mar 2021 at 01:15, Sean Christopherson wrote:
>
> +Thomas
>
> On Mon, Mar 29, 2021, Wanpeng Li wrote:
> > From: Wanpeng Li
> >
> > The bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=209831
> > reported that the guest time remains 0 when running a while true
> > loop in the guest.
(patch [2/5]).
Next, adjust the teo governor a bit so that negative "sleep length" values
are counted like zero by it (patch [3/5]) and modify it so as to avoid
mishandling negative "sleep length" values (patch [4/5]).
Finally, make the menu governor take negative "sleep le
From: "Rafael J. Wysocki"
Modify the TEO governor to take possible negative return values of
tick_nohz_get_next_hrtimer() into account by changing the data type
of some variables used by it to s64 which allows it to carry out
computations without potentially problematic data type c
From: "Rafael J. Wysocki"
Subject: [PATCH] cpuidle: menu: Take negative "sleep length" values into account
Make the menu governor check the tick_nohz_get_next_hrtimer()
return value so as to avoid dealing with negative "sleep length"
values and make it use that v
+Thomas
On Mon, Mar 29, 2021, Wanpeng Li wrote:
> From: Wanpeng Li
>
> The bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=209831
> reported that the guest time remains 0 when running a while true
> loop in the guest.
>
> The commit 87fa7f3e98a131 ("x86/kvm: Move context tracking where i
From: Wanpeng Li
The bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=209831
reported that the guest time remains 0 when running a while true
loop in the guest.
The commit 87fa7f3e98a131 ("x86/kvm: Move context tracking where it
belongs") moves guest_exit_irqoff() close to vmexit breaks t
Allow page counters to be more readily modified by callers which have
a folio. Name these wrappers with 'stat' instead of 'state' as requested
by Linus here:
https://lore.kernel.org/linux-mm/CAHk-=wj847sudr-kt+46ft3+xffgiwpgthvm7djwgdi4cvr...@mail.gmail.com/
Signed-off-by: Matthew Wilcox (Oracle)
On Wed, Mar 17, 2021 at 3:19 PM Sean Christopherson wrote:
>
> On Wed, Mar 17, 2021, Sean Christopherson wrote:
> > On Wed, Mar 17, 2021, Borislav Petkov wrote:
> > > IOW, you have c_bit so your valid address space is [0 .. c_bit-1] no?
> >
> > I haven't found anything in the GHCB that dictates th
On Wed, Mar 17, 2021, Sean Christopherson wrote:
> On Wed, Mar 17, 2021, Borislav Petkov wrote:
> > IOW, you have c_bit so your valid address space is [0 .. c_bit-1] no?
>
> I haven't found anything in the GHCB that dictates that MAXPHYADDR == C_BIT-1,
> or more specifically that MAXPHYADDR == C_B
overlaps MAXPHYADDR (%d bits).
> > VMM is buggy or malicious, overriding MAXPHYADDR to %d.\n"
>
> Not sure about that. This will make a lot of users run scared, not
> knowing what's going on and open bugzillas.
Yeah, I'm not too sure about it either. I would not
make a lot of users run scared, not
knowing what's going on and open bugzillas.
> +
> static void early_detect_mem_encrypt(struct cpuinfo_x86 *c)
> {
> u64 msr;
>
> + /*
> + * When running as an SEV guest of any flavor, update the physical
>
/*
+* When running as an SEV guest of any flavor, update the physical
+* address width to account for the C-bit and clear all of the SME/SVE
+* feature flags. As far as the kernel is concerned, the SEV flags
+* enumerate what features can be use
> +static inline
> +void __inc_zone_folio_stat(struct folio *folio, enum zone_stat_item item)
This prototype style is weird and doesn't follow either of the preffered
styles..
> static inline void __mod_zone_freepage_state(struct zone *zone, int nr_pages,
>
From: Greg Kroah-Hartman
From: Ioana Ciornei
[ Upstream commit 73f476aa1975bae6a792b340f5b26ffcfba869a6 ]
The previous implementation of .handle_interrupt() did not take into
account the fact that all the interrupt status registers should be
acknowledged since multiple interrupt sources could
On Sun, 14 Mar 2021 04:11:55 + Matthew Wilcox wrote:
> On Sat, Mar 13, 2021 at 12:37:07PM -0800, Andrew Morton wrote:
> > On Fri, 5 Mar 2021 04:18:39 + "Matthew Wilcox (Oracle)"
> > wrote:
> >
> > > Allow page counters to be more readily modified by callers which have
> > > a folio.
On Sat, Mar 13, 2021 at 12:37:07PM -0800, Andrew Morton wrote:
> On Fri, 5 Mar 2021 04:18:39 + "Matthew Wilcox (Oracle)"
> wrote:
>
> > Allow page counters to be more readily modified by callers which have
> > a folio. Name these wrappers with 'stat' instead of 'state' as requested
> > by
On Fri, 5 Mar 2021 04:18:39 + "Matthew Wilcox (Oracle)"
wrote:
> Allow page counters to be more readily modified by callers which have
> a folio. Name these wrappers with 'stat' instead of 'state' as requested
> by Linus here:
> https://lore.kernel.org/linux-mm/CAHk-=wj847sudr-kt+46ft3+xff
urn the correct number of pages
freed(issued by current shrinker).
The fix is simple:
1. account the number of pages freed in zs_compact locally.
2. use actomic variable pages_compacted to accumulate total number.
Link: https://lkml.kernel.org/r/20210202122235.26885-1-wu-...@tcl.com
Fi
urn the correct number of pages
freed(issued by current shrinker).
The fix is simple:
1. account the number of pages freed in zs_compact locally.
2. use actomic variable pages_compacted to accumulate total number.
Link: https://lkml.kernel.org/r/20210202122235.26885-1-wu-...@tcl.com
Fi
urn the correct number of pages
freed(issued by current shrinker).
The fix is simple:
1. account the number of pages freed in zs_compact locally.
2. use actomic variable pages_compacted to accumulate total number.
Link: https://lkml.kernel.org/r/20210202122235.26885-1-wu-...@tcl.com
Fi
urn the correct number of pages
freed(issued by current shrinker).
The fix is simple:
1. account the number of pages freed in zs_compact locally.
2. use actomic variable pages_compacted to accumulate total number.
Link: https://lkml.kernel.org/r/20210202122235.26885-1-wu-...@tcl.com
Fi
urn the correct number of pages
freed(issued by current shrinker).
The fix is simple:
1. account the number of pages freed in zs_compact locally.
2. use actomic variable pages_compacted to accumulate total number.
Link: https://lkml.kernel.org/r/20210202122235.26885-1-wu-...@tcl.com
Fi
urn the correct number of pages
freed(issued by current shrinker).
The fix is simple:
1. account the number of pages freed in zs_compact locally.
2. use actomic variable pages_compacted to accumulate total number.
Link: https://lkml.kernel.org/r/20210202122235.26885-1-wu-...@tcl.com
Fi
Allow page counters to be more readily modified by callers which have
a folio. Name these wrappers with 'stat' instead of 'state' as requested
by Linus here:
https://lore.kernel.org/linux-mm/CAHk-=wj847sudr-kt+46ft3+xffgiwpgthvm7djwgdi4cvr...@mail.gmail.com/
Signed-off-by: Matthew Wilcox (Oracle)
On Wed, Mar 03, 2021 at 11:18:43PM +0800, Muchun Song wrote:
> For simplification 991e7673859e ("mm: memcontrol: account kernel stack
> per node") has changed the per zone vmalloc backed stack pages
> accounting to per node. By doing that we have lost a certain precision
&g
For simplification 991e7673859e ("mm: memcontrol: account kernel stack
per node") has changed the per zone vmalloc backed stack pages
accounting to per node. By doing that we have lost a certain precision
because those pages might live in different NUMA nodes. In the end
NR_KERNE
On Wed, Mar 03, 2021 at 05:39:56PM +0800, Muchun Song wrote:
> For simplification 991e7673859e ("mm: memcontrol: account kernel stack
> per node") has changed the per zone vmalloc backed stack pages
> accounting to per node. By doing that we have lost a certain precision
&g
On Wed, Mar 3, 2021 at 6:02 AM Michal Hocko wrote:
>
[...]
> > > > + BUG_ON(vm->nr_pages != THREAD_SIZE / PAGE_SIZE);
> > >
> > > I do not think we need this BUG_ON. What kind of purpose does it serve?
> >
> > vm->nr_pages should be always equal to THREAD_SIZE / PAGE_SIZE
> > if the sy
On Wed 03-03-21 21:27:24, Muchun Song wrote:
> On Wed, Mar 3, 2021 at 6:25 PM Michal Hocko wrote:
> >
> > On Wed 03-03-21 17:39:56, Muchun Song wrote:
> > > For simplification 991e7673859e ("mm: memcontrol: account kernel stack
> > > per node") has chan
On Wed, Mar 3, 2021 at 6:25 PM Michal Hocko wrote:
>
> On Wed 03-03-21 17:39:56, Muchun Song wrote:
> > For simplification 991e7673859e ("mm: memcontrol: account kernel stack
> > per node") has changed the per zone vmalloc backed stack pages
> > accounting to pe
On Wed 03-03-21 17:39:56, Muchun Song wrote:
> For simplification 991e7673859e ("mm: memcontrol: account kernel stack
> per node") has changed the per zone vmalloc backed stack pages
> accounting to per node. By doing that we have lost a certain precision
> because tho
For simplification 991e7673859e ("mm: memcontrol: account kernel stack
per node") has changed the per zone vmalloc backed stack pages
accounting to per node. By doing that we have lost a certain precision
because those pages might live in different NUMA nodes. In the end
NR_KERNE
On Tue, Mar 02, 2021 at 08:33:20PM +0100, Michal Hocko wrote:
> On Tue 02-03-21 10:50:32, Roman Gushchin wrote:
> > On Tue, Mar 02, 2021 at 03:37:33PM +0800, Muchun Song wrote:
> > > The alloc_thread_stack_node() cannot guarantee that allocated stack pages
> > > are in the same node when CONFIG_VMA
On Tue 02-03-21 10:50:32, Roman Gushchin wrote:
> On Tue, Mar 02, 2021 at 03:37:33PM +0800, Muchun Song wrote:
> > The alloc_thread_stack_node() cannot guarantee that allocated stack pages
> > are in the same node when CONFIG_VMAP_STACK. Because we do not specify
> > __GFP_THISNODE to __vmalloc_nod
c_page_state() for each page one by one.
Hm, I actually wonder if it makes any sense to split the stack over multiple
nodes? Maybe we should fix this instead?
>
> Fixes: 991e7673859e ("mm: memcontrol: account kernel stack per node")
> Signed-off-by: Muchun Song
> ---
> ke
> > __GFP_THISNODE to __vmalloc_node_range().
>
> Instead of __GFP_THISNODE, mention that the kernel_clone() passes
> NUMA_NO_NODE which is being used for __vmalloc_node_range().
If we really want to do this then I would recommend reasoning in the
following line:
"
For simplification 991e767385
ion that the kernel_clone() passes
NUMA_NO_NODE which is being used for __vmalloc_node_range().
> Fix it by caling
calling
> mod_lruvec_page_state() for each page one by one.
>
> Fixes: 991e7673859e ("mm: memcontrol: account kernel stack per node")
> Signed-off-by: Muchun Song
On Tue, Mar 2, 2021 at 1:34 AM Michal Hocko wrote:
>
[snip]
> > Yeah, imprecision may
> > not be a problem. But if this is what we did deliberately, I think that
> > it is better to add a comment there. Thanks.
>
> Yes the comment is quite confusing. I suspect it meant to say
> /* All stac
On Tue, Mar 2, 2021 at 5:34 PM Michal Hocko wrote:
>
> On Tue 02-03-21 17:23:42, Muchun Song wrote:
> > On Tue, Mar 2, 2021 at 4:44 PM Michal Hocko wrote:
> > >
> > > On Tue 02-03-21 15:37:33, Muchun Song wrote:
> > > > The alloc_thread_stack_node() cannot guarantee that allocated stack
> > > >
On Tue 02-03-21 17:23:42, Muchun Song wrote:
> On Tue, Mar 2, 2021 at 4:44 PM Michal Hocko wrote:
> >
> > On Tue 02-03-21 15:37:33, Muchun Song wrote:
> > > The alloc_thread_stack_node() cannot guarantee that allocated stack pages
> > > are in the same node when CONFIG_VMAP_STACK. Because we do no
cision may
not be a problem. But if this is what we did deliberately, I think that
it is better to add a comment there. Thanks.
>
> > Fixes: 991e7673859e ("mm: memcontrol: account kernel stack per node")
> > Signed-off-by: Muchun Song
> > ---
> > kernel/fork.c | 1
1e7673859e ("mm: memcontrol: account kernel stack per node")
> Signed-off-by: Muchun Song
> ---
> kernel/fork.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/fork.c b/kernel/fork.c
> index d66cd1014211..6e2201feb5
ntrol: account kernel stack per node")
Signed-off-by: Muchun Song
---
kernel/fork.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index d66cd1014211..6e2201feb524 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -379,14 +379,19
to
commit the transaction.
We use the space_info->total_bytes_pinned to approximate how much space
we have pinned. It's approximate because if we remove a reference to an
extent we may free it, but there may be more references to it than we
know of at that point, but we account it as pinn
From: Brett Creeley
[ Upstream commit a6aa7c8f998f4afddd73410aa043dad38162ce9e ]
Currently if an AVF driver doesn't account for the possibility of a
port VLAN when determining its max packet size then packets at MTU will
be dropped. It is not the VF driver's responsibility to account
1 - 100 of 1398 matches
Mail list logo
