On 2021/2/19 20:16, Frederic Weisbecker wrote:
> On Mon, Nov 23, 2020 at 09:22:08PM +0800, Yunfeng Ye wrote:
>> In realtime scenarios, the "nohz_full" parameter is configured. Tick
>> interference is not expected when there is only one realtime thread.
>> But w
It's not a good way to access the phys_proc_id of cpuinfo directly.
So using topology_physical_package_id(cpu) instead.
Signed-off-by: Yunfeng Ye
---
drivers/powercap/intel_rapl_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/powercap/intel_rapl_common.c
b
It's not a good way to access phys_proc_id and cpu_die_id directly.
So using topology_physical_package_id(cpu) and topology_die_id(cpu)
instead.
Signed-off-by: Yunfeng Ye
---
drivers/powercap/intel_rapl_common.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers
On 2020/12/17 21:59, Frederic Weisbecker wrote:
> On Thu, Dec 17, 2020 at 02:51:58PM +0800, Yunfeng Ye wrote:
>>
>>
>> On 2020/12/15 22:47, Frederic Weisbecker wrote:
>>> On Tue, Dec 15, 2020 at 08:06:34PM +0800, Yunfeng Ye wrote:
>>>> The idle_exit
On 2020/12/15 22:47, Frederic Weisbecker wrote:
> On Tue, Dec 15, 2020 at 08:06:34PM +0800, Yunfeng Ye wrote:
>> The idle_exittime field of tick_sched is used to record the time when
>> the idle state was left. but currently the idle_exittime is updated in
tick_nohz_full_update_tick
tick_nohz_restart_sched_tick
ts->idle_exittime = now;
So move to tick_nohz_stop_idle() to make the idle_exittime update
correctly.
Signed-off-by: Yunfeng Ye
---
kernel/time/tick-sched.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
tick_nohz_full_update_tick
tick_nohz_restart_sched_tick
ts->idle_exittime = now;
So move to tick_nohz_stop_idle() to make the idle_exittime update
correctly.
Signed-off-by: Yunfeng Ye
---
kernel/time/tick-sched.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
On 2020/12/4 17:40, Mel Gorman wrote:
> On Fri, Dec 04, 2020 at 09:22:34AM +0800, Yunfeng Ye wrote:
>>
>>
>> On 2020/12/3 17:42, Mel Gorman wrote:
>>> On Thu, Dec 03, 2020 at 02:47:14PM +0800, Yunfeng Ye wrote:
>>>> The schedstat include runqueu
On 2020/12/3 17:42, Mel Gorman wrote:
> On Thu, Dec 03, 2020 at 02:47:14PM +0800, Yunfeng Ye wrote:
>> The schedstat include runqueue-specific stats and domain-specific stats,
>> so split it into two functions, show_rqstat() and show_domainstat().
>>
>> No functiona
The schedstat include runqueue-specific stats and domain-specific stats,
so split it into two functions, show_rqstat() and show_domainstat().
No functional changes.
Signed-off-by: Yunfeng Ye
---
kernel/sched/stats.c | 101 +++
1 file changed, 54
A little clean up that moving the '\n' to the prior seq_printf. and
remove the separate seq_printf which for line breaks.
No functional changes.
Signed-off-by: Yunfeng Ye
---
kernel/sched/stats.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/kernel/sched/stats.c b
On 2020/11/27 20:15, Frederic Weisbecker wrote:
> On Mon, Nov 23, 2020 at 09:22:08PM +0800, Yunfeng Ye wrote:
>> In realtime scenarios, the "nohz_full" parameter is configured. Tick
>> interference is not expected when there is only one realtime thread.
>> But w
to restart the tick timer
when there is only one realtime thread. Adding can_stop_full_tick()
before restarting the tick, if it return true, keep tick stopped.
Signed-off-by: Yunfeng Ye
---
kernel/time/tick-sched.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/k
The following commit has been merged into the timers/core branch of tip:
Commit-ID: 94ad2e3cedb82af034f6d97c58022f162b669f9b
Gitweb:
https://git.kernel.org/tip/94ad2e3cedb82af034f6d97c58022f162b669f9b
Author:Yunfeng Ye
AuthorDate:Tue, 17 Nov 2020 14:19:46 +01:00
Committer
The following commit has been merged into the timers/core branch of tip:
Commit-ID: 896b969e6732b68ee3c12ae4e1aeddf5db99bc46
Gitweb:
https://git.kernel.org/tip/896b969e6732b68ee3c12ae4e1aeddf5db99bc46
Author:Yunfeng Ye
AuthorDate:Tue, 17 Nov 2020 14:19:48 +01:00
Committer
in pwq_adjust_max_active() said:
"Need to kick a worker after thawed or an unbound wq's
max_active is bumped"
So it is unnecessary to kick a kworker for percpu's wq when invoking
alloc_workqueue(). this patch only kick a worker based on the actual
activation of delayed works.
Signed-off-by:
On 2020/11/19 9:58, Lai Jiangshan wrote:
> On Wed, Nov 18, 2020 at 5:05 PM Yunfeng Ye wrote:
>>
>>
>>
>> On 2020/11/18 14:26, Yunfeng Ye wrote:
>>>
>>>
>>> On 2020/11/18 12:06, Lai Jiangshan wrote:
>>>> On Tue, Nov 17, 2020 at
On 2020/11/18 14:26, Yunfeng Ye wrote:
>
>
> On 2020/11/18 12:06, Lai Jiangshan wrote:
>> On Tue, Nov 17, 2020 at 3:33 PM Yunfeng Ye wrote:
>>>
>>> In realtime scenario, We do not want to have interference on the
>>> isolated cpu cores. but whe
On 2020/11/18 12:06, Lai Jiangshan wrote:
> On Tue, Nov 17, 2020 at 3:33 PM Yunfeng Ye wrote:
>>
>> In realtime scenario, We do not want to have interference on the
>> isolated cpu cores. but when invoking alloc_workqueue() for percpu wq
>> on the housekee
in pwq_adjust_max_active() said:
"Need to kick a worker after thawed or an unbound wq's
max_active is bumped"
So it is unnecessary to kick a kworker for percpu wq's when
alloc_workqueue. this patch only kick a worker after thawed or for an
unbound workqueue.
Signed-off-by: Yunfeng Ye
---
kernel/w
On 2020/11/16 19:29, Thomas Gleixner wrote:
> On Mon, Nov 16 2020 at 14:07, Yunfeng Ye wrote:
>> On 2020/11/16 3:43, Thomas Gleixner wrote:
>>>> and the conflict between jiffies_lock and jiffies_seq increases,
>>>> especially in multi-core scenarios.
On 2020/11/16 3:43, Thomas Gleixner wrote:
> On Wed, Nov 11 2020 at 17:11, Yunfeng Ye wrote:
>> When nohz or nohz_full is configured, the concurrency calls of
>> tick_do_update_jiffies64 increases,
>
> Why?
>
When nohz=off, tick_do_update_jiffies64() is calle
the critical region of the jiffies_seq
can be reduced to reduce latency overheads. By the way,
last_jiffies_update is protected by jiffies_lock, so reducing the
jiffies_seq critical area is safe.
Signed-off-by: Yunfeng Ye
---
kernel/time/tick-sched.c | 5 ++---
1 file changed, 2 insertions(+), 3
On 2020/8/22 19:35, Thomas Gleixner wrote:
> On Sat, Aug 22 2020 at 17:33, Yunfeng Ye wrote:
>> On 2020/8/13 16:27, Thomas Gleixner wrote:
>> For example, the cmdline "irqaffinity=0,1,126,127" on the 128 cores system：
>>
>> [root@localhost ~]# cat /proc/i
On 2020/8/13 16:27, Thomas Gleixner wrote:
> Yunfeng Ye writes:
>
>> When the "affinity=" cmdline parameter is configured,
>
> There is no such parameter.
>
>> the interrupt affinity displayed in the proc directory does not match
>> with tha
The "managed_irq" for isolcpus is supported after the commit
11ea68f553e2 ("genirq, sched/isolation: Isolate from handling managed
interrupts"), but the interrupt affinity shown in proc directory is
still the original affinity.
So modify the interrupt affinity correctly for managed_irq.
When the "affinity=" cmdline parameter is configured, the interrupt
affinity displayed in the proc directory does not match with that of the
the percu interrupt, and the percu interrupt uses desc->percu_affinity.
So show desc->percu_affinity in show_irq_affinity() for percpu
interrupt.
Switch to bitmap_zalloc() to show clearly in __create_xol_area().
No functional change.
Signed-off-by: Yunfeng Ye
---
kernel/events/uprobes.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index ece7e13f6e4a
Switch to bitmap_zalloc() to show clearly in dma_init_coherent_memory().
No functional change.
Signed-off-by: Yunfeng Ye
---
kernel/dma/coherent.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/kernel/dma/coherent.c b/kernel/dma/coherent.c
index 2a0c4985f38e
A warning was found by smatch tool:
"check_template() error: testing array offset 'c' after use."
Fix it by removing the useless checking in check_template().
Signed-off-by: Yunfeng Ye
---
lib/842/842_compress.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/lib/842/842_co
A warning was found by smatch tool:
"add_template() error: testing array offset 'c' after use."
Fix it by removing the useless checking in add_template().
Signed-off-by: Yunfeng Ye
---
lib/842/842_compress.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/lib/842/842_compre
or indicating
bootconfig explicitly")
Fixes: 950313ebf79c ("tools: bootconfig: Add bootconfig command")
Acked-by: Masami Hiramatsu
Signed-off-by: Yunfeng Ye
Signed-off-by: Steven Rostedt (VMware)
---
v3 -> v4:
- update the commit message
v2 -> v3:
- set 'ret' to 0 befo
On 2020/5/8 19:30, Markus Elfring wrote:
>> this change can fix the warning of tools.
>
> Would you like to point any specific source code analysis tools out
> for this issue?
> (Can a corresponding attribution become relevant for a clearer
> change description?)
>
The tools we used is not
On 2020/5/8 19:03, Markus Elfring wrote:
> …
>> +++ b/tools/bootconfig/main.c
>> @@ -314,31 +314,35 @@ int apply_xbc(const char *path, const char *xbc_path)
> …
>> +free_data:
>> free(data);
> …
>
> Would any software users prefer to omit the memory release for
> a quicker program
iramatsu
Signed-off-by: Yunfeng Ye
Signed-off-by: Steven Rostedt (VMware)
---
v2 -> v3:
- set 'ret' to 0 before returning on success
v1 -> v2:
- complete the error handling at other error path
- add "Fixes" tag
tools/bootconfig/main.c | 18 +++---
1 file changed, 11 inser
On 2020/5/8 17:30, Dan Carpenter wrote:
> On Fri, May 08, 2020 at 02:51:15PM +0800, Yunfeng Ye wrote:
>> diff --git a/tools/bootconfig/main.c b/tools/bootconfig/main.c
>> index 16b9a420e6fd..d034f86022b7 100644
>> --- a/tools/bootconfig/main.c
>> +++ b/tools/boot
iramatsu
Signed-off-by: Yunfeng Ye
Signed-off-by: Steven Rostedt (VMware)
---
tools/bootconfig/main.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/tools/bootconfig/main.c b/tools/bootconfig/main.c
index 16b9a420e6fd..d034f86022b7 100644
--- a/tools/bootconfi
On 2020/5/8 4:30, Markus Elfring wrote:
>> The @data and @fd is leak in the error path of apply_xbc(), so this
>> patch fix it.
>
> I suggest to improve this change description.
>
> * Please use an imperative wording.
>
> * Would you like to add the tag “Fixes”?
>
>
>> +++
There are some common codes for stack checking, so factors it out into
the function on_stack().
No functional change.
Signed-off-by: Yunfeng Ye
---
v1 -> v2:
- check 'low' in on_stack() and everybody call on_stack() only
arch/arm64/include/asm/stacktrace.h |
On 2020/5/7 21:52, Will Deacon wrote:
> On Thu, May 07, 2020 at 05:28:19PM +0800, Yunfeng Ye wrote:
>> diff --git a/arch/arm64/include/asm/stacktrace.h
>> b/arch/arm64/include/asm/stacktrace.h
>> index fdb913cc0bcb..b92bef2fb6cd 100644
>> --- a/arch/arm64/include/asm
There are some common codes for stack checking, so factors it out into
the function on_stack() and on_valid_stack().
No functional change.
Signed-off-by: Yunfeng Ye
---
arch/arm64/include/asm/stacktrace.h | 53 +
arch/arm64/kernel/sdei.c| 28
The @data and @fd is leak in the error path of apply_xbc(), so this
patch fix it.
Signed-off-by: Yunfeng Ye
---
tools/bootconfig/main.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/tools/bootconfig/main.c b/tools/bootconfig/main.c
index 16b9a420e6fd..001076c51712
On 2019/10/16 22:25, Arnaldo Carvalho de Melo wrote:
> Em Wed, Oct 16, 2019 at 09:50:17PM +0800, Yunfeng Ye escreveu:
>> There are memory leaks and file descriptor resource leaks in
>> process_mapfile() and main().
>>
>> Fix this by adding free(), fclose
, reducing the time interval will increase the messages
output, so remove the "Retry ..." message, instead, track time and
output to the the sucessful message.
Signed-off-by: Yunfeng Ye
Reviewed-by: Sudeep Holla
---
v5 -> v6:
- add "Reviewed-by:"
v4 -> v5:
- track time i
, reducing the time interval will increase the messages
output, so remove the "Retry ..." message, instead, track time and
output to the the sucessful message.
Signed-off-by: Yunfeng Ye
---
v4 -> v5:
- track time instead of loop counter
v3 -> v4:
- using time_before(jiffies, t
On 2019/10/18 23:20, Sudeep Holla wrote:
> On Fri, Oct 18, 2019 at 08:46:37PM +0800, Yunfeng Ye wrote:
>> In case like suspend-to-disk and uspend-to-ram, a large number of CPU
>
> s/case/cases/
> s/uspend-to-ram/suspend-to-ram/
>
ok, thanks.
>> cores need to be shu
The following commit has been merged into the perf/urgent branch of tip:
Commit-ID: 6080728ff8e9c9116e52e6f840152356ac2fea56
Gitweb:
https://git.kernel.org/tip/6080728ff8e9c9116e52e6f840152356ac2fea56
Author:Yunfeng Ye
AuthorDate:Tue, 15 Oct 2019 16:30:08 +08:00
Committer
The following commit has been merged into the perf/urgent branch of tip:
Commit-ID: ae199c580da1754a2b051321eeb76d6dacd8707b
Gitweb:
https://git.kernel.org/tip/ae199c580da1754a2b051321eeb76d6dacd8707b
Author:Yunfeng Ye
AuthorDate:Tue, 15 Oct 2019 10:54:14 +08:00
Committer
The following commit has been merged into the perf/urgent branch of tip:
Commit-ID: 1abecfcaa7bba21c9985e0136fa49836164dd8fd
Gitweb:
https://git.kernel.org/tip/1abecfcaa7bba21c9985e0136fa49836164dd8fd
Author:Yunfeng Ye
AuthorDate:Wed, 16 Oct 2019 16:38:45 +08:00
Committer
The following commit has been merged into the perf/core branch of tip:
Commit-ID: 8a9f91c51ea72b126864e0db616b1bac12261200
Gitweb:
https://git.kernel.org/tip/8a9f91c51ea72b126864e0db616b1bac12261200
Author:Yunfeng Ye
AuthorDate:Mon, 14 Oct 2019 16:14:59 +08:00
Committer
The following commit has been merged into the perf/core branch of tip:
Commit-ID: d7e78706e43107fa269fe34b1a69e653f5ec9f2c
Gitweb:
https://git.kernel.org/tip/d7e78706e43107fa269fe34b1a69e653f5ec9f2c
Author:Yunfeng Ye
AuthorDate:Mon, 14 Oct 2019 16:15:57 +08:00
Committer
, reducing the time interval will increase the messages
output, so remove the "Retry ..." message, instead, put the number of
waiting times to the sucessful message.
Signed-off-by: Yunfeng Ye
---
v3 -> v4:
- using time_before(jiffies, timeout) to check
- update the comment as review sugg
On 2019/10/18 19:41, Mark Rutland wrote:
> On Fri, Oct 18, 2019 at 07:24:14PM +0800, Yunfeng Ye wrote:
>> In a case like suspend-to-disk, a large number of CPU cores need to be
>> shut down. At present, the CPU hotplug operation is serialised, and the
>> CPU cores can
On 2019/10/18 19:45, Sudeep Holla wrote:
> On Fri, Oct 18, 2019 at 07:24:14PM +0800, Yunfeng Ye wrote:
>> In a case like suspend-to-disk, a large number of CPU cores need to be
>
> Add suspend-to-ram also to list, i.e.
> "In case like suspend-to-disk and suspend
interval will increase the messages output,
so remove the "Retry ..." message, instead, put the number of waiting
times to the sucessful message.
Signed-off-by: Yunfeng Ye
---
v2 -> v3:
- update the comment
- remove the busy-wait logic, modify the loop logic and output message
v1
On 2019/10/17 21:54, Sudeep Holla wrote:
> On Thu, Oct 17, 2019 at 09:26:15PM +0800, Yunfeng Ye wrote:
>>
>>
>> On 2019/10/16 23:32, Sudeep Holla wrote:
>>> On Wed, Oct 09, 2019 at 12:45:16PM +0800, Yunfeng Ye wrote:
>>>> If psci_ops.affini
On 2019/10/17 22:00, David Laight wrote:
> From: Yunfeng Ye
>> Sent: 17 October 2019 14:26
> ...
>>>> - for (i = 0; i < 10; i++) {
>>>> + i = 0;
>>>> + timeout = jiffies + msecs_to_jiffies(100);
>>>> + do {
>&
On 2019/10/16 23:05, Sudeep Holla wrote:
> On Wed, Oct 16, 2019 at 07:29:59PM +0800, Yunfeng Ye wrote:
>>
>>
>> On 2019/10/16 18:25, Sudeep Holla wrote:
>>> On Wed, Oct 16, 2019 at 11:22:23AM +0800, Yunfeng Ye wrote:
>>>>
>>>>
On 2019/10/16 23:32, Sudeep Holla wrote:
> On Wed, Oct 09, 2019 at 12:45:16PM +0800, Yunfeng Ye wrote:
>> If psci_ops.affinity_info() fails, it will sleep 10ms, which will not
>> take so long in the right case. Use usleep_range() instead of msleep(),
>> reduce the w
On 2019/10/16 22:06, Arnaldo Carvalho de Melo wrote:
> Em Wed, Oct 16, 2019 at 09:26:50PM +0800, Yunfeng Ye escreveu:
>> The memory @orig_flags is allocated by strdup(), it is freed on the
>> normal path, but leak to free on the error path.
>>
>> Fix this by adding fr
On 2019/10/16 22:08, Arnaldo Carvalho de Melo wrote:
> Em Wed, Oct 16, 2019 at 09:19:54PM +0800, Yunfeng Ye escreveu:
>>
>>
>> On 2019/10/16 21:09, Arnaldo Carvalho de Melo wrote:
>>> Em Wed, Oct 16, 2019 at 10:04:03AM -0300, Arnaldo Carvalho de Melo escreveu:
>
Make build fail on JSON parse error")
Fixes: e9d32c1bf0cd ("perf vendor events: Add support for arch standard events")
Signed-off-by: Yunfeng Ye
---
v1 -> v2:
- add free(eventsfp) to fix eventsfp resource leaks
- add free_arch_std_events() on the error path
tools/perf/pmu-event
The memory @orig_flags is allocated by strdup(), it is freed on the
normal path, but leak to free on the error path.
Fix this by adding free(orig_flags) on the error path.
Fixes: 0e5644b3 ("perf kmem: Print gfp flags in human readable string")
Signed-off-by: Yunfeng Ye
---
v1 -&g
On 2019/10/16 21:09, Arnaldo Carvalho de Melo wrote:
> Em Wed, Oct 16, 2019 at 10:04:03AM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Wed, Oct 16, 2019 at 04:38:45PM +0800, Yunfeng Ye escreveu:
>>> The memory @orig_flags is allocated by strdup(), it is freed on the
>>
On 2019/10/16 20:08, John Garry wrote:
+ ret = -1;
+ goto out;
>>>
>>> There's a subtle change of behaviour here, i.e. now calling
>>> print_mapping_table_suffix(), but I don't think that it makes any
>>> difference.
>>>
>> yes, I know that "goto out" will run
On 2019/10/16 18:25, Sudeep Holla wrote:
> On Wed, Oct 16, 2019 at 11:22:23AM +0800, Yunfeng Ye wrote:
>>
>>
>> On 2019/10/16 0:23, Will Deacon wrote:
>>> Hi,
>>>
>>> On Sat, Sep 21, 2019 at 07:21:17PM +0800, Yunfeng Ye wrote:
>>>>
On 2019/10/16 18:40, John Garry wrote:
> On 16/10/2019 08:47, Yunfeng Ye wrote:
>> There are memory leaks and file descriptor resource leaks in
>> process_mapfile().
>>
>> Fix this by adding free() and fclose() on the error paths.
>>
>> Fixes: 80eeb67f
The memory @orig_flags is allocated by strdup(), it is freed on the
normal path, but leak to free on the error path.
Fix this by adding free(orig_flags) on the error path.
Signed-off-by: Yunfeng Ye
---
tools/perf/builtin-kmem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/perf
There are memory leaks and file descriptor resource leaks in
process_mapfile().
Fix this by adding free() and fclose() on the error paths.
Fixes: 80eeb67fe577 ("perf jevents: Program to convert JSON file")
Signed-off-by: Yunfeng Ye
---
tools/perf/pmu-events/jevents.c | 9 +++
On 2019/10/16 0:23, Will Deacon wrote:
> Hi,
>
> On Sat, Sep 21, 2019 at 07:21:17PM +0800, Yunfeng Ye wrote:
>> If psci_ops.affinity_info() fails, it will sleep 10ms, which will not
>> take so long in the right case. Use usleep_range() instead of msleep(),
>> reduce
n name checking to rm_rf")
Signed-off-by: Yunfeng Ye
---
tools/perf/util/header.c | 4 +++-
tools/perf/util/util.c | 6 --
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 86d9396..becc2d1 100644
--- a/tools/perf
There is a memory leak problem in the failure paths of
build_cl_output(), so fix it.
Signed-off-by: Yunfeng Ye
---
tools/perf/builtin-c2c.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index 3542b6a
Currently perf_mmap_alloc_page() is used to allocate memory in
rb_alloc(), but using free_page() to free memory in the failure path.
It's better to use perf_mmap_free_page() instead.
Signed-off-by: Yunfeng Ye
---
kernel/events/ring_buffer.c | 20 ++--
1 file changed, 10
-by: Yunfeng Ye
---
kernel/events/ring_buffer.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c
index ffb59a4..abc145c 100644
--- a/kernel/events/ring_buffer.c
+++ b/kernel/events/ring_buffer.c
@@ -799,9 +799,9 @@ struct
The async_lock is big global lock, and kfree() is not always cheap, it
will increase lock contention. it's better let kfree() outside the lock
to keep the critical area as short as possible.
Signed-off-by: Yunfeng Ye
Reviewed-by: Alexander Duyck
Reviewed-by: Bart Van Assche
---
v1 ->
If psci_ops.affinity_info() fails, it will sleep 10ms, which will not
take so long in the right case. Use usleep_range() instead of msleep(),
reduce the waiting time, and give a chance to busy wait before sleep.
Signed-off-by: Yunfeng Ye
---
V1->V2:
- use usleep_range() instead of udelay() af
On 2019/10/8 18:25, Will Deacon wrote:
> On Tue, Oct 08, 2019 at 10:33:17AM +0800, Yunfeng Ye wrote:
>> On 2019/10/7 23:37, Will Deacon wrote:
>>> On Mon, Oct 07, 2019 at 06:06:35PM +0800, Yunfeng Ye wrote:
>>>> @@ -617,25 +624,47 @@ static int t16_setend_handler(s
On 2019/10/7 23:37, Will Deacon wrote:
> On Mon, Oct 07, 2019 at 06:06:35PM +0800, Yunfeng Ye wrote:
>> There are no return value checking when using kzalloc() and kcalloc() for
>> memory allocation. so add it.
>>
>> Signed-off-by: Yunfeng Ye
>> ---
>>
There are no return value checking when using kzalloc() and kcalloc() for
memory allocation. so add it.
Signed-off-by: Yunfeng Ye
---
v1 -> v2:
- return error code when memory allocation failure
arch/arm64/kernel/armv8_deprecated.c | 57 +++-
1 file changed,
kzalloc() is used for cma bitmap allocation in cma_activate_area(),
switch to bitmap_zalloc() is more clearly.
Signed-off-by: Yunfeng Ye
---
mm/cma.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/mm/cma.c b/mm/cma.c
index 7fe0b83..be55d19 100644
--- a/mm/cma.c
+++ b
On 2019/9/30 21:22, Will Deacon wrote:
> On Sun, Sep 29, 2019 at 12:44:17PM +0800, Yunfeng Ye wrote:
>> There are no return value checking when using kzalloc() and kcalloc() for
>> memory allocation. so add it.
>>
>> Signed-off-by: Yunfeng Ye
>> ---
>> a
kzalloc() is used for cma bitmap allocation in cma_activate_area(),
switch to bitmap_zalloc() is more clearly.
Signed-off-by: Yunfeng Ye
---
mm/cma.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/mm/cma.c b/mm/cma.c
index 7fe0b83..be55d19 100644
--- a/mm/cma.c
+++ b
There are no return value checking when using kzalloc() and kcalloc() for
memory allocation. so add it.
Signed-off-by: Yunfeng Ye
---
arch/arm64/kernel/armv8_deprecated.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/kernel/armv8_deprecated.c
b/arch/arm64/kernel
Currently perf_mmap_alloc_page() is used to allocate memory in
rb_alloc(), but using free_page() to free memory in the failure path.
It's better to use perf_mmap_free_page() instead.
Signed-off-by: Yunfeng Ye
---
kernel/events/ring_buffer.c | 20 ++--
1 file changed, 10
-by: Yunfeng Ye
---
kernel/events/ring_buffer.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c
index ffb59a4..abc145c 100644
--- a/kernel/events/ring_buffer.c
+++ b/kernel/events/ring_buffer.c
@@ -799,9 +799,9 @@ struct
The async_lock is big global lock, and kfree() is not always cheap, it
will increase lock contention. it's better let kfree() outside the lock
to keep the critical area as short as possible.
Signed-off-by: Yunfeng Ye
Reviewed-by: Alexander Duyck
Reviewed-by: Bart Van Assche
---
v1 ->
current_is_async() can be implemented using current_work(), it's better
not to be aware of the workqueue's internal information.
Signed-off-by: Yunfeng Ye
Reviewed-by: Bart Van Assche
---
v1 -> v2:
- add "Reviewed-by"
kernel/async.c | 6 ++
1 file changed, 2 insertions(+)
On 2019/9/26 23:27, Bart Van Assche wrote:
> On 9/26/19 1:40 AM, Yunfeng Ye wrote:
>> current_is_async() can be implemented using current_work(), it's better
>> not to be aware of the workqueue's internal information.
>
> Reviewed-by: Bart Van Assche
>
I will update
On 2019/9/26 23:18, Bart Van Assche wrote:
> On 9/26/19 4:06 AM, David Sterba wrote:
>> On Thu, Sep 26, 2019 at 03:58:36PM +0800, Yunfeng Ye wrote:
>>> The async_lock is big global lock, I think it's good to put kfree() outside
>>> to keep the critical area as shor
current_is_async() can be implemented using current_work(), it's better
not to be aware of the workqueue's internal information.
Signed-off-by: Yunfeng Ye
---
kernel/async.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/kernel/async.c b/kernel/async.c
index 1de270d
On 2019/9/25 23:20, Alexander Duyck wrote:
> On Wed, 2019-09-25 at 20:52 +0800, Yunfeng Ye wrote:
>> It's not necessary to put kfree() in the critical area of the lock, so
>> let it out.
>>
>> Signed-off-by: Yunfeng Ye
>> ---
>> kernel/async.c | 6 +++---
pear to be a linux kernel source tree.
Don't check the ipc dir in checkpatch.pl and get_maintainer.pl.
Signed-off-by: Yunfeng Ye
---
v1 -> v2:
- update the subject "scripts:" instead of "toplevel:"
scripts/checkpatch.pl | 2 +-
scripts/get_maintainer.pl | 1 -
2 files cha
On 2019/9/26 0:32, Joe Perches wrote:
> On Wed, 2019-09-25 at 20:37 +0800, Yunfeng Ye wrote:
>> After the commit 76128326f97c ("toplevel: Move ipc/ to kernel/ipc/: move
>> the files"), we met some error messages:
>>
>> ./scripts/checkpatch.pl:
>
On 2019/9/25 21:38, gre...@linuxfoundation.org wrote:
> On Wed, Sep 25, 2019 at 08:52:26PM +0800, Yunfeng Ye wrote:
>> It's not necessary to put kfree() in the critical area of the lock, so
>> let it out.
>>
>> Signed-off-by: Yunfeng Ye
>> ---
>> kerne
It's not necessary to put kfree() in the critical area of the lock, so
let it out.
Signed-off-by: Yunfeng Ye
---
kernel/async.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/async.c b/kernel/async.c
index 4f9c1d6..1de270d 100644
--- a/kernel/async.c
+++ b
pear to be a linux kernel source tree.
Don't check the ipc dir in checkpatch.pl and get_maintainer.pl.
Signed-off-by: Yunfeng Ye
---
scripts/checkpatch.pl | 2 +-
scripts/get_maintainer.pl | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/ch
memblock_alloc_exact_nid_raw() for this situation, which allocate
boot memory block on the exact node. If a large contiguous block memory
allocate fail in sparse_buffer_init(), it will fall back to allocate
small block memory base section.
Signed-off-by: Yunfeng Ye
Reviewed-by: Mike Rapoport
---
v3 ->
On 2019/9/25 15:32, Mike Rapoport wrote:
> On Wed, Sep 25, 2019 at 03:18:43PM +0800, Yunfeng Ye wrote:
>> sparse_buffer_init() use memblock_alloc_try_nid_raw() to allocate memory
>> for page management structure, if memory allocation fails from specified
>> node, it will
memblock_alloc_exact_nid_raw() for this situation, which allocate
boot memory block on the exact node. If a large contiguous block memory
allocate fail in sparse_buffer_init(), it will fall back to allocate
small block memory base section.
Signed-off-by: Yunfeng Ye
---
v2 -> v3:
- use "bool e
On 2019/9/25 14:36, Mike Rapoport wrote:
> On Tue, Sep 24, 2019 at 04:09:32PM +0800, Yunfeng Ye wrote:
>> sparse_buffer_init() use memblock_alloc_try_nid_raw() to allocate memory
>> for page management structure, if memory allocation fails from specified
>> node, it will
1 - 100 of 112 matches
Mail list logo
