On 04/08/2023 23:19, Stefano Stabellini wrote:
On Fri, 4 Aug 2023, Nicola Vetrini wrote:
The variable declared in the header file
'xen/arch/x86/include/asm/e820.h'
is shadowed by many function parameters, so it is renamed to avoid
these
violations.
No functional changes.
Signed-off-by: Nicol
On 04/08/2023 23:24, Stefano Stabellini wrote:
On Fri, 4 Aug 2023, Nicola Vetrini wrote:
s/mpc_default_type/mpc_default in 'xen/arch/x86/include/asm/mpspec.h'
to avoid clashing with function parameter names in 'mpparse.c'.
No functional changes.
Signed-off-by: Nicola Vetrini
---
Even though t
On 04/08/2023 22:47, Stefano Stabellini wrote:
On Fri, 4 Aug 2023, Nicola Vetrini wrote:
The extern variable 'irq_desc' defined in 'irq.h' is shadowed by
local variables in the changed file. To avoid this, the variable is
renamed to 'irq_description'.
No functional change.
Signed-off-by: Nicol
On 04.08.2023 22:26, Stefano Stabellini wrote:
> On Fri, 4 Aug 2023, Jan Beulich wrote:
>> On 03.08.2023 16:22, Nicola Vetrini wrote:
>>> On 03/08/2023 11:01, Jan Beulich wrote:
On 03.08.2023 04:13, Stefano Stabellini wrote:
> On Wed, 2 Aug 2023, Nicola Vetrini wrote:
>> @@ -1169,8 +11
On 04.08.2023 16:09, Nicola Vetrini wrote:
>>> 3. One possible resolution pattern is including 'acglobal.h' twice
>>> (either directly or indirectly trough acpi.h, if
>>> the latter does not cause other issues) like so:
>>>
>>> (assuming DEFINE_ACPI_GLOBALS is undefined here)
>>> #inclu
On 04.08.2023 16:00, Nicola Vetrini wrote:
>>
>> Upon further examination, I identified the following patterns:
>>
>> 1. Functions defined in .c called only from asm code (e.g., the
>> already mentioned __start_xen)
>> 2. Functions/variables declared in a .h, defined in a .c that does not
>> includ
On 04.08.2023 17:27, Nicola Vetrini wrote:
> The variable declared in the header file 'xen/arch/x86/include/asm/e820.h'
> is shadowed by many function parameters, so it is renamed to avoid these
> violations.
>
> No functional changes.
>
> Signed-off-by: Nicola Vetrini
> ---
> This patch is simi
On 04.08.2023 17:27, Nicola Vetrini wrote:
> The types u{8,16,32,64} defined in 'xen/arch/x86/include/asm/types.h'
> shadow the variables in the modified function, hence violating Rule 5.3.
> Therefore, the rename takes care of the shadowing.
>
> No functional changes.
>
> Signed-off-by: Nicola V
On 03/08/2023 11:17, Jan Beulich wrote:
On 02.08.2023 16:38, Nicola Vetrini wrote:
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -2233,6 +2233,7 @@ static bool sched_tasklet_check_cpu(unsigned int
cpu)
/* fallthrough */
case TASKLET_enqueued|TASKLET_scheduled:
On 04.08.2023 17:27, Nicola Vetrini wrote:
> --- a/xen/include/xen/delay.h
> +++ b/xen/include/xen/delay.h
> @@ -5,6 +5,6 @@
>
> #include
> #define mdelay(n) (\
> - {unsigned long msec=(n); while (msec--) udelay(1000);})
> + {unsigned long msec_=(n); while (msec_--) udelay(1000);})
As
Anthony Liguori:
> From: Jan H. Schönherr
>
> Intel says for CPUID leaf 0Bh:
>
> "Software must not use EBX[15:0] to enumerate processor
>topology of the system. This value in this field
>(EBX[15:0]) is only intended for display/diagnostic
>purposes. The actual number of logical pr
On 04.08.2023 17:27, Nicola Vetrini wrote:
> Rename the local variables to avoid clashing with function 'xstate'
> defined below, but declared in the corresponding header file.
Hmm, there are two functions with such a local variable, but you don't
change those. You change "xsave" instead. The new
On 04.08.2023 17:27, Nicola Vetrini wrote:
> The macros defined 'xen/include/public/arch-x86/xen-mca.h' have needless
> underscore prefixes for parameter names and variable names that cause
> shadowing with e.g. the variable 'i' in function 'mce_action'.
> Therefore, the renaming aims to resolve pr
On 07.08.2023 10:18, Simon Gaiser wrote:
> Anthony Liguori:
>> From: Jan H. Schönherr
>>
>> Intel says for CPUID leaf 0Bh:
>>
>> "Software must not use EBX[15:0] to enumerate processor
>>topology of the system. This value in this field
>>(EBX[15:0]) is only intended for display/diagnosti
On 04.08.2023 16:11, Federico Serafini wrote:
> Give a name to unnamed parameters to address violations of
> MISRA C:2012 Rule 8.2 ("Function types shall be in prototype form with
> named parameters").
> Keep consistency between object and function declarations thus
> addressing violations of MISRA
On 07.08.2023 10:13, Nicola Vetrini wrote:
> On 03/08/2023 11:17, Jan Beulich wrote:
>> On 02.08.2023 16:38, Nicola Vetrini wrote:
>>> --- a/xen/common/sched/core.c
>>> +++ b/xen/common/sched/core.c
>>> @@ -2233,6 +2233,7 @@ static bool sched_tasklet_check_cpu(unsigned int
>>> cpu)
>>> /*
On 07/08/2023 10:09, Jan Beulich wrote:
On 04.08.2023 17:27, Nicola Vetrini wrote:
The variable declared in the header file
'xen/arch/x86/include/asm/e820.h'
is shadowed by many function parameters, so it is renamed to avoid
these
violations.
No functional changes.
Signed-off-by: Nicola Vetr
Hi Jan,
On 07/08/2023 09:14, Jan Beulich wrote:
On 04.08.2023 17:27, Nicola Vetrini wrote:
--- a/xen/include/xen/delay.h
+++ b/xen/include/xen/delay.h
@@ -5,6 +5,6 @@
#include
#define mdelay(n) (\
- {unsigned long msec=(n); while (msec--) udelay(1000);})
+ {unsigned long ms
On 03.08.2023 14:05, Oleksii Kurochko wrote:
> will be used in the patch "xen/riscv: introduce
> decode_cause() stuff" and requires
While as it stands the description is accurate, I don't think that later
patch has a need to include xen/lib.h anymore. xen/macros.h will do, I
think.
Also please
On 07/08/23 10:44, Jan Beulich wrote:
On 04.08.2023 16:11, Federico Serafini wrote:
Give a name to unnamed parameters to address violations of
MISRA C:2012 Rule 8.2 ("Function types shall be in prototype form with
named parameters").
Keep consistency between object and function declarations thus
On 07/08/2023 10:11, Jan Beulich wrote:
On 04.08.2023 17:27, Nicola Vetrini wrote:
The types u{8,16,32,64} defined in 'xen/arch/x86/include/asm/types.h'
shadow the variables in the modified function, hence violating Rule
5.3.
Therefore, the rename takes care of the shadowing.
No functional ch
On 07.08.2023 10:59, Nicola Vetrini wrote:
> On 07/08/2023 10:09, Jan Beulich wrote:
>> On 04.08.2023 17:27, Nicola Vetrini wrote:
>>> The variable declared in the header file
>>> 'xen/arch/x86/include/asm/e820.h'
>>> is shadowed by many function parameters, so it is renamed to avoid
>>> these
>>
On 07.08.2023 11:01, Julien Grall wrote:
> On 07/08/2023 09:14, Jan Beulich wrote:
>> On 04.08.2023 17:27, Nicola Vetrini wrote:
>>> --- a/xen/include/xen/delay.h
>>> +++ b/xen/include/xen/delay.h
>>> @@ -5,6 +5,6 @@
>>>
>>> #include
>>> #define mdelay(n) (\
>>> - {unsigned long msec=(n);
Hi!
Something in XEN/PV time management seems to be seriously broken:
timekeeping watchdog on CPU9: Marking clocksource 'tsc' as unstable because the
skew is too large:
[ 152.557154] clocksource: 'xen' wd_nsec: 511979417
wd_now: 24e4d7625e wd_last: 24c65332c5 mask: ff
On 07/08/2023 10:23, Jan Beulich wrote:
On 04.08.2023 17:27, Nicola Vetrini wrote:
Rename the local variables to avoid clashing with function 'xstate'
defined below, but declared in the corresponding header file.
Hmm, there are two functions with such a local variable, but you don't
change tho
Give a name to unnamed parameters to address violations of
MISRA C:2012 Rule 8.2 ("Function types shall be in prototype form with
named parameters").
Keep consistency between parameter types used in function
declarations and the ones used in the corresponding function
definitions, thus addressing v
On 07/08/2023 11:15, Jan Beulich wrote:
On 07.08.2023 11:01, Julien Grall wrote:
On 07/08/2023 09:14, Jan Beulich wrote:
On 04.08.2023 17:27, Nicola Vetrini wrote:
--- a/xen/include/xen/delay.h
+++ b/xen/include/xen/delay.h
@@ -5,6 +5,6 @@
#include
#define mdelay(n) (\
- {unsigned
On 07.08.2023 11:23, Nicola Vetrini wrote:
> On 07/08/2023 11:15, Jan Beulich wrote:
>> On 07.08.2023 11:01, Julien Grall wrote:
>>> On 07/08/2023 09:14, Jan Beulich wrote:
On 04.08.2023 17:27, Nicola Vetrini wrote:
> --- a/xen/include/xen/delay.h
> +++ b/xen/include/xen/delay.h
>
On 07/08/2023 10:32, Jan Beulich wrote:
On 07.08.2023 11:23, Nicola Vetrini wrote:
On 07/08/2023 11:15, Jan Beulich wrote:
On 07.08.2023 11:01, Julien Grall wrote:
On 07/08/2023 09:14, Jan Beulich wrote:
On 04.08.2023 17:27, Nicola Vetrini wrote:
--- a/xen/include/xen/delay.h
+++ b/xen/in
On 07.08.2023 11:23, Federico Serafini wrote:
> Give a name to unnamed parameters to address violations of
> MISRA C:2012 Rule 8.2 ("Function types shall be in prototype form with
> named parameters").
> Keep consistency between parameter types used in function
> declarations and the ones used in t
It seems some firmwares put dummy entries in the ACPI MADT table for non
existing processors. On my NUC11TNHi5 those have the invalid APIC ID
0xff. Linux already has code to handle those cases both in
acpi_parse_lapic [1] as well as in acpi_parse_x2apic [2]. So add the
same check to Xen.
Note that
Jan Beulich:
> On 31.07.2023 12:32, Simon Gaiser wrote:
>> --- a/xen/arch/x86/io_apic.c
>> +++ b/xen/arch/x86/io_apic.c
>> @@ -1967,6 +1967,8 @@ static void __init check_timer(void)
>>
>> if ( timer_irq_works() )
>> {
>> +printk(XENLOG_INFO "IRQ test with
On 07.08.2023 11:47, Simon Gaiser wrote:
> Jan Beulich:
>> On 31.07.2023 12:32, Simon Gaiser wrote:
>>> --- a/xen/arch/x86/io_apic.c
>>> +++ b/xen/arch/x86/io_apic.c
>>> @@ -1967,6 +1967,8 @@ static void __init check_timer(void)
>>>
>>> if ( timer_irq_works() )
>>> {
>>>
Jan Beulich:
> On 07.08.2023 10:18, Simon Gaiser wrote:
>> Anthony Liguori:
>>> From: Jan H. Schönherr
>>>
>>> Intel says for CPUID leaf 0Bh:
>>>
>>> "Software must not use EBX[15:0] to enumerate processor
>>>topology of the system. This value in this field
>>>(EBX[15:0]) is only intende
On 07/08/2023 10:31, Jan Beulich wrote:
On 04.08.2023 17:27, Nicola Vetrini wrote:
The macros defined 'xen/include/public/arch-x86/xen-mca.h' have
needless
underscore prefixes for parameter names and variable names that cause
shadowing with e.g. the variable 'i' in function 'mce_action'.
Theref
On 07/08/2023 10:38 am, Simon Gaiser wrote:
> It seems some firmwares put dummy entries in the ACPI MADT table for non
> existing processors. On my NUC11TNHi5 those have the invalid APIC ID
> 0xff. Linux already has code to handle those cases both in
> acpi_parse_lapic [1] as well as in acpi_parse_
On 07.08.2023 11:58, Simon Gaiser wrote:
> Jan Beulich:
>> On 07.08.2023 10:18, Simon Gaiser wrote:
>>> Anthony Liguori:
From: Jan H. Schönherr
Intel says for CPUID leaf 0Bh:
"Software must not use EBX[15:0] to enumerate processor
topology of the system. This val
On 07/08/2023 11:01 am, Andrew Cooper wrote:
> On 07/08/2023 10:38 am, Simon Gaiser wrote:
>> It seems some firmwares put dummy entries in the ACPI MADT table for non
>> existing processors. On my NUC11TNHi5 those have the invalid APIC ID
>> 0xff. Linux already has code to handle those cases both i
On 07/08/2023 9:18 am, Simon Gaiser wrote:
> Anthony Liguori:
>> From: Jan H. Schönherr
>>
>> Intel says for CPUID leaf 0Bh:
>>
>> "Software must not use EBX[15:0] to enumerate processor
>>topology of the system. This value in this field
>>(EBX[15:0]) is only intended for display/diagnos
On 07.08.2023 11:38, Simon Gaiser wrote:
> It seems some firmwares put dummy entries in the ACPI MADT table for non
> existing processors. On my NUC11TNHi5 those have the invalid APIC ID
> 0xff. Linux already has code to handle those cases both in
> acpi_parse_lapic [1] as well as in acpi_parse_x2a
flight 182208 qemu-mainline real [real]
flight 182211 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/182208/
http://logs.test-lab.xenproject.org/osstest/logs/182211/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
Andrew Cooper:
> On 07/08/2023 11:01 am, Andrew Cooper wrote:
>> On 07/08/2023 10:38 am, Simon Gaiser wrote:
>>> It seems some firmwares put dummy entries in the ACPI MADT table for non
>>> existing processors. On my NUC11TNHi5 those have the invalid APIC ID
>>> 0xff. Linux already has code to hand
One further question is whether functions under
'xen/common/coverage/gcov_base.c' should gain
a declaration in 'gcov.h' or not, as they exist just for the purpose
of
being referenced
by autogenerated profiling code. I see no reason why they shouldn't,
but
they can also be safely deviated,
sinc
fs (9)
failed: 0
skipped: 0
successful run completed in 60.01s (1 min, 0.01 secs)
We can see that the ops/s has hardly changed.
This series is based on next-20230807.
Comments and suggestions are welcome.
Thanks,
Qi
Changelog in v3 -> v4:
- [PATCH v3 01/49] has been merged, so discard it.
- fix
The following functions are only used inside the mm subsystem, so it's
better to move their declarations to the mm/internal.h file.
1. shrinker_debugfs_add()
2. shrinker_debugfs_detach()
3. shrinker_debugfs_remove()
Signed-off-by: Qi Zheng
---
include/linux/shrinker.h | 19 ---
The mm/vmscan.c file is too large, so separate the shrinker-related
code from it into a separate file. No functional changes.
Signed-off-by: Qi Zheng
---
mm/Makefile | 4 +-
mm/internal.h | 2 +
mm/shrinker.c | 709 ++
mm/vmscan.c | 701 ---
The debugfs_remove_recursive() will wait for debugfs_file_put() to return,
so the shrinker will not be freed when doing debugfs operations (such as
shrinker_debugfs_count_show() and shrinker_debugfs_scan_write()), so there
is no need to hold shrinker_rwsem during debugfs operations.
Signed-off-by:
Currently, the shrinker instances can be divided into the following three
types:
a) global shrinker instance statically defined in the kernel, such as
workingset_shadow_shrinker.
b) global shrinker instance statically defined in the kernel modules, such
as mmu_shrinker in x86.
c) shrinker
Use new APIs to dynamically allocate the x86-mmu shrinker.
Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
---
arch/x86/kvm/mmu/mmu.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 9e4cd8b4a202..0386
Use new APIs to dynamically allocate the android-binder shrinker.
Signed-off-by: Qi Zheng
---
drivers/android/binder_alloc.c | 31 +++
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c
index
Use new APIs to dynamically allocate the thp-zero and thp-deferred_split
shrinkers.
Signed-off-by: Qi Zheng
---
mm/huge_memory.c | 69 +++-
1 file changed, 45 insertions(+), 24 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 947001
Use new APIs to dynamically allocate the sunrpc_cred shrinker.
Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
---
net/sunrpc/auth.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/net/sunrpc/auth.c b/net/sunrpc/auth.c
index 2f16f9d17966..0cc52e39f859
Use new APIs to dynamically allocate the mm-shadow shrinker.
Signed-off-by: Qi Zheng
---
mm/workingset.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/mm/workingset.c b/mm/workingset.c
index da58a26d0d4d..3c53138903a7 100644
--- a/mm/workingset
In preparation for implementing lockless slab shrink, use new APIs to
dynamically allocate the i915_gem_mm shrinker, so that it can be freed
asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
read-side critical section when releasing the struct drm_i915_private.
Signed-off-by:
In preparation for implementing lockless slab shrink, use new APIs to
dynamically allocate the drm-msm_gem shrinker, so that it can be freed
asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
read-side critical section when releasing the struct msm_drm_private.
Signed-off-by: Q
In preparation for implementing lockless slab shrink, use new APIs to
dynamically allocate the drm-panfrost shrinker, so that it can be freed
asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
read-side critical section when releasing the struct panfrost_device.
Signed-off-by:
In preparation for implementing lockless slab shrink, use new APIs to
dynamically allocate the dm-bufio shrinker, so that it can be freed
asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
read-side critical section when releasing the struct dm_bufio_client.
Signed-off-by: Qi Z
In preparation for implementing lockless slab shrink, use new APIs to
dynamically allocate the dm-zoned-meta shrinker, so that it can be freed
asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
read-side critical section when releasing the struct dmz_metadata.
Signed-off-by: Qi
In preparation for implementing lockless slab shrink, use new APIs to
dynamically allocate the mbcache shrinker, so that it can be freed
asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
read-side critical section when releasing the struct mb_cache.
Signed-off-by: Qi Zheng
Re
In preparation for implementing lockless slab shrink, use new APIs to
dynamically allocate the md-bcache shrinker, so that it can be freed
asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
read-side critical section when releasing the struct cache_set.
Signed-off-by: Qi Zheng
In preparation for implementing lockless slab shrink, use new APIs to
dynamically allocate the jbd2-journal shrinker, so that it can be freed
asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
read-side critical section when releasing the struct journal_s.
Signed-off-by: Qi Zhe
Use new APIs to dynamically allocate the nfs-xattr shrinkers.
Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
---
fs/nfs/nfs42xattr.c | 87 +++--
1 file changed, 44 insertions(+), 43 deletions(-)
diff --git a/fs/nfs/nfs42xattr.c b/fs/nfs/nfs42xattr.c
in
Use new APIs to dynamically allocate the rcu-lazy shrinker.
Signed-off-by: Qi Zheng
---
kernel/rcu/tree_nocb.h | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/kernel/rcu/tree_nocb.h b/kernel/rcu/tree_nocb.h
index 5598212d1f27..e1c59c33738a 100644
--- a/k
Use new APIs to dynamically allocate the xen-backend shrinker.
Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
---
drivers/xen/xenbus/xenbus_probe_backend.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/xen/xenbus/xenbus_probe_backend.c
b/driv
Use new APIs to dynamically allocate the rcu-kfree shrinker.
Signed-off-by: Qi Zheng
---
kernel/rcu/tree.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 7c79480bfaa0..3b20fc46c514 100644
--- a/kernel/rcu/tr
Use new APIs to dynamically allocate the nfs-acl shrinker.
Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
---
fs/nfs/super.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index 2284f749d892..1b5cd0444dda 100644
---
Use new APIs to dynamically allocate the ubifs-slab shrinker.
Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
---
fs/ubifs/super.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index b08fb28d16b5..c690782388a8 1
In preparation for implementing lockless slab shrink, use new APIs to
dynamically allocate the vmw-balloon shrinker, so that it can be freed
asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
read-side critical section when releasing the struct vmballoon.
And we can simply exit
In preparation for implementing lockless slab shrink, use new APIs to
dynamically allocate the md-raid5 shrinker, so that it can be freed
asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
read-side critical section when releasing the struct r5conf.
Signed-off-by: Qi Zheng
Rev
In preparation for implementing lockless slab shrink, use new APIs to
dynamically allocate the ext4-es shrinker, so that it can be freed
asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
read-side critical section when releasing the struct ext4_sb_info.
Signed-off-by: Qi Zheng
Besides the one you listed, there are these other occurrences:
- xen/arch/x86/mm.c:4678 in 'arch_memory_op' as local variable 'struct
e820entry'
This probably wants renaming; my suggestion would be just "e" here.
Ok
- xen/arch/x86/include/asm/guest/hypervisor.h:55 in
'hypervisor_e820_fi
In preparation for implementing lockless slab shrink, use new APIs to
dynamically allocate the virtio-balloon shrinker, so that it can be freed
asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
read-side critical section when releasing the struct virtio_balloon.
Signed-off-by:
Use new APIs to dynamically allocate the f2fs-shrinker.
Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
---
fs/f2fs/super.c | 32
1 file changed, 24 insertions(+), 8 deletions(-)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index aa1f9a3a8037..9092310582aa 1
Use new APIs to dynamically allocate the drm-ttm_pool shrinker.
Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
---
drivers/gpu/drm/ttm/ttm_pool.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/t
Use new APIs to dynamically allocate the erofs-shrinker.
Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
---
fs/erofs/utils.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/fs/erofs/utils.c b/fs/erofs/utils.c
index cc6fb9e98899..6e1a828e6ca3 100644
--
Use new APIs to dynamically allocate the gfs2-qd shrinker.
Signed-off-by: Qi Zheng
---
fs/gfs2/main.c | 6 +++---
fs/gfs2/quota.c | 26 --
fs/gfs2/quota.h | 3 ++-
3 files changed, 25 insertions(+), 10 deletions(-)
diff --git a/fs/gfs2/main.c b/fs/gfs2/main.c
index af
Use new APIs to dynamically allocate the nfsd-filecache shrinker.
Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
---
fs/nfsd/filecache.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/fs/nfsd/filecache.c b/fs/nfsd/filecache.c
index ee9c923192e0..
Use new APIs to dynamically allocate the dquota-cache shrinker.
Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
---
fs/quota/dquot.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/fs/quota/dquot.c b/fs/quota/dquot.c
index 9e72bfe8bbad..c303cffdf433 1006
Use new APIs to dynamically allocate the gfs2-glock shrinker.
Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
---
fs/gfs2/glock.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
index 1438e7465e30..8d582ba7514f 100644
In preparation for implementing lockless slab shrink, use new APIs to
dynamically allocate the xfs-inodegc shrinker, so that it can be freed
asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
read-side critical section when releasing the struct xfs_mount.
Signed-off-by: Qi Zhen
Now there are no readers of shrinker_rwsem, so we can simply replace it
with mutex lock.
Signed-off-by: Qi Zheng
---
drivers/md/dm-cache-metadata.c | 2 +-
fs/super.c | 2 +-
mm/shrinker.c | 28 ++--
mm/shrinker_debug.c|
Hi Henry,
On 01/08/2023 04:44, Henry Wang wrote:
CAUTION: This message has originated from an External Source. Please use proper
judgment and caution when opening attachments, clicking links, or responding to
this email.
From: Wei Chen
At the moment, on MMU system, enable_mmu() will return
In preparation for implementing lockless slab shrink, use new APIs to
dynamically allocate the xfs-buf shrinker, so that it can be freed
asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
read-side critical section when releasing the struct xfs_buftarg.
Signed-off-by: Qi Zheng
The shrinker_rwsem is a global read-write lock in shrinkers subsystem,
which protects most operations such as slab shrink, registration and
unregistration of shrinkers, etc. This can easily cause problems in the
following cases.
1) When the memory pressure is high and there are many filesystems
Currently, the synchronize_shrinkers() is only used by TTM pool. It only
requires that no shrinkers run in parallel.
After we use RCU+refcount method to implement the lockless slab shrink,
we can not use shrinker_rwsem or synchronize_rcu() to guarantee that all
shrinker invocations have seen an up
In preparation for implementing lockless slab shrink, use new APIs to
dynamically allocate the xfs-qm shrinker, so that it can be freed
asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
read-side critical section when releasing the struct xfs_quotainfo.
Signed-off-by: Qi Zheng
Now no users are using the old APIs, just remove them.
Signed-off-by: Qi Zheng
Reviewed-by: Muchun Song
---
include/linux/shrinker.h | 7 --
mm/shrinker.c| 143 ---
2 files changed, 150 deletions(-)
diff --git a/include/linux/shrinker.h b/inclu
Like global slab shrink, this commit also uses refcount+RCU method to make
memcg slab shrink lockless.
Use the following script to do slab shrink stress test:
```
DIR="/root/shrinker/memcg/mnt"
do_create()
{
mkdir -p /sys/fs/cgroup/memory/test
echo 4G > /sys/fs/cgroup/memory/test/memory
In preparation for implementing lockless slab shrink, use new APIs to
dynamically allocate the nfsd-client shrinker, so that it can be freed
asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
read-side critical section when releasing the struct nfsd_net.
Signed-off-by: Qi Zheng
For now, reparent_shrinker_deferred() is the only holder of read lock of
shrinker_rwsem. And it already holds the global cgroup_mutex, so it will
not be called in parallel.
Therefore, in order to convert shrinker_rwsem to shrinker_mutex later,
here we change to hold the write lock of shrinker_rwse
In preparation for implementing lockless slab shrink, use new APIs to
dynamically allocate the s_shrink, so that it can be freed asynchronously
using kfree_rcu(). Then it doesn't need to wait for RCU read-side critical
section when releasing the struct super_block.
Signed-off-by: Qi Zheng
Reviewe
Currently, we maintain two linear arrays per node per memcg, which are
shrinker_info::map and shrinker_info::nr_deferred. And we need to resize
them when the shrinker_nr_max is exceeded, that is, allocate a new array,
and then copy the old array to the new array, and finally free the old
array by R
In preparation for implementing lockless slab shrink, use new APIs to
dynamically allocate the nfsd-reply shrinker, so that it can be freed
asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
read-side critical section when releasing the struct nfsd_net.
Signed-off-by: Qi Zheng
In preparation for implementing lockless slab shrink, use new APIs to
dynamically allocate the mm-zspool shrinker, so that it can be freed
asynchronously using kfree_rcu(). Then it doesn't need to wait for RCU
read-side critical section when releasing the struct zs_pool.
Signed-off-by: Qi Zheng
R
As far as I understand the HPET legacy mode is not required after the
timer IRQ test. For previous discussion see [1] and [2]. Keeping it
enabled prevents reaching deeper C-states on some systems and thereby
also S0ix residency. So disable it after the timer IRQ test worked. Note
that this code pat
Hi Ayan,
> -Original Message-
> Hi Henry,
>
> > At the moment, on MMU system, enable_mmu() will return to an
> > address in the 1:1 mapping, then each path is responsible to
> > switch to virtual runtime mapping. Then remove_identity_mapping()
> > is called on the boot CPU to remove all
On 07/08/2023 12:35, Henry Wang wrote:
Hi Ayan,
-Original Message-
Hi Henry,
At the moment, on MMU system, enable_mmu() will return to an
address in the 1:1 mapping, then each path is responsible to
switch to virtual runtime mapping. Then remove_identity_mapping()
is called on the b
On 07/08/2023 12:35, Henry Wang wrote:
Hi Ayan,
Hi Henry,
-Original Message-
Hi Henry,
At the moment, on MMU system, enable_mmu() will return to an
address in the 1:1 mapping, then each path is responsible to
switch to virtual runtime mapping. Then remove_identity_mapping()
is ca
On 07/08/2023 12:43, Ayan Kumar Halder wrote:
On 07/08/2023 12:35, Henry Wang wrote:
Hi Ayan,
-Original Message-
Hi Henry,
At the moment, on MMU system, enable_mmu() will return to an
address in the 1:1 mapping, then each path is responsible to
switch to virtual runtime mapping.
Hi Julien,
> -Original Message-
> Subject: Re: [PATCH v4 01/13] xen/arm64: head.S: Introduce
> enable_{boot,secondary}_cpu_mm
> >> prefer "enable_boot_cpu_mmu" as it is MMU specific as well.
> >
> > ...this, are the name suggested by Julien in [1], so probably I will stick
> > to these nam
1 - 100 of 239 matches
Mail list logo
