[PATCH] sched: check pinned tasks before nohz balance, linux-4.2-rc5

Rezki From ed5c294addcb472be0d5c3619c5a7e0e9d34c3c5 Mon Sep 17 00:00:00 2001 From: Uladzislau Rezki ure...@gmail.com Date: Wed, 5 Aug 2015 16:20:50 +0200 Subject: [PATCH] sched: check pinned tasks before balance The problem is there are pinned tasks in the system which can not be migrated

[RFC,v2 2/3] sched: set number of iterations to h_nr_running

From: Uladzislau 2 Rezki It is possible that busiest run queue has multiple RT tasks, whereas no CFS tasks, that is why it is reasonable to use h_nr_running instead, because a load balance only applies for CFS related tasks. Signed-off-by: Uladzislau 2 Rezki

[RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

From: Uladzislau 2 Rezki A load balancer calculates imbalance factor for particular shed domain and tries to steal up the prescribed amount of weighted load. However, a small imbalance factor would sometimes prevent us from stealing any tasks at all. When a CPU

[RFC,v2 1/3] sched: set loop_max after rq lock is taken

From: Uladzislau 2 Rezki While doing a load balance there is a race in setting loop_max variable since nr_running can be changed causing incorect iteration loops. As a result we may skip some candidates or check the same tasks again. Signed-off-by: Uladzislau

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

load of tasks in favour >> of just moving _something_ already, is utterly dangerous if not coupled >> with these two other conditions, so arguably that too should be under >> CONFIG_PREEMPT. >> > I see your point. Will round both with CONFIG_PREEMPT. > I have upload a new patch, please find it here: https://lkml.org/lkml/2017/2/14/334 -- Uladzislau Rezki

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

> > On Wed, 2017-02-08 at 09:43 +0100, Uladzislau Rezki wrote: > > From: Uladzislau 2 Rezki <uladzislau2.re...@sonymobile.com> > > > > A load balancer calculates imbalance factor for particular shed >

[PATCH] sched: ignore task_h_load for CPU_NEWLY_IDLE

From: Uladzislau 2 Rezki A load balancer calculates imbalance factor for particular sched domain and tries to steal up the prescribed amount of weighted load. However, a small imbalance factor would sometimes prevent us from stealing any tasks at all. When a CPU

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

On Mon, Feb 13, 2017 at 2:51 PM, Peter Zijlstra <pet...@infradead.org> wrote: > On Thu, Feb 09, 2017 at 07:54:05PM +0100, Uladzislau Rezki wrote: > >> > Does this patch make an actual difference, if so how much and with >> > what workload? >> > >>

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

On Wed, Feb 15, 2017 at 7:58 PM, Dietmar Eggemann <dietmar.eggem...@arm.com> wrote: > On 02/14/2017 06:28 PM, Uladzislau Rezki wrote: >>>> >>>> >>>> So that is useful information that should have been in the Changelog. >>>> >>>

Re: [RFC,v2 2/3] sched: set number of iterations to h_nr_running

On Thu, Feb 9, 2017 at 1:20 PM, Peter Zijlstra <pet...@infradead.org> wrote: > On Wed, Feb 08, 2017 at 09:43:28AM +0100, Uladzislau Rezki wrote: >> From: Uladzislau 2 Rezki <uladzislau2.re...@sonymobile.com> >> >> It is possible that busiest run queue has multiple

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

On Thu, Feb 9, 2017 at 1:22 PM, Peter Zijlstra <pet...@infradead.org> wrote: > On Wed, Feb 08, 2017 at 09:43:29AM +0100, Uladzislau Rezki wrote: >> From: Uladzislau 2 Rezki <uladzislau2.re...@sonymobile.com> >> >> A load balancer calculates imbalance factor for pa

[RFC 2/3] sched: set number of iterations to h_nr_running

From: Uladzislau 2 Rezki It is possible that busiest run queue has multiple RT tasks, whereas no CFS tasks, that is why it is reasonable to use h_nr_running instead, because a load balance only applies for CFS related tasks. Signed-off-by: Uladzislau 2 Rezki

[RFC 1/3] sched: set loop_max after rq lock is taken

From: Uladzislau 2 Rezki While doing a load balance there is a race in setting loop_max variable since nr_running can be changed causing incorect iteration loops. As a result we may skip some candidates or check the same tasks again. Signed-off-by: Uladzislau

[RFC 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

From: Uladzislau 2 Rezki A load balancer calculates imbalance factor for particular shed domain and tries to steal up the prescribed amount of weighted load. However, a small imbalance factor would sometimes prevent us from stealing any tasks at all. When a CPU

Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE

Hello. Let's decide how to proceed with https://lkml.org/lkml/2017/2/14/334 patch. Despite it is not a big change, i think it is important and ready to be submited, unless there are still any comments. -- Uladzislau Rezki On Thu, Feb 16, 2017 at 12:20 PM, Uladzislau Rezki <ure...@gmail.

Re: [RFC v1] sched/fair: search a task from the tail of the queue

On Mon, Aug 28, 2017 at 10:41:55AM +0200, Peter Zijlstra wrote: > On Fri, Aug 25, 2017 at 12:11:31AM +0200, Uladzislau Rezki (Sony) wrote: > > From: Uladzislau Rezki <ure...@gmail.com> > > > > As a first step this patch makes cfs_tasks list as MRU one. > >

Re: [RFC v1] sched/fair: search a task from the tail of the queue

On Mon, Aug 28, 2017 at 10:41 AM, Peter Zijlstra <pet...@infradead.org> wrote: > On Fri, Aug 25, 2017 at 12:11:31AM +0200, Uladzislau Rezki (Sony) wrote: >> From: Uladzislau Rezki <ure...@gmail.com> >> >> As a first step this patch makes cfs_tasks list as MRU o

Re: [RFC][PATCH]: sched/fair: search a task from the tail of the queue

On Thu, Aug 24, 2017 at 7:46 PM, Peter Zijlstra <pet...@infradead.org> wrote: > > On Thu, Aug 24, 2017 at 12:44:45PM +0200, Uladzislau Rezki (Sony) wrote: > > From: Uladzislau Rezki <ure...@gmail.com> > > > > When a task is enqueued back from a physical CPU

Re: [PATCH RFC 1/2] sched: Minimize the idle cpu selection race window.

On Fri, Nov 24, 2017 at 07:46:30PM +0100, Mike Galbraith wrote: > On Fri, 2017-11-24 at 11:26 +0100, Uladzislau Rezki wrote: > > > > I guess there is misunderstanding here. The main goal is not to cover > > pinned case, for sure. I was thinking more about below poin

Re: [PATCH RFC 1/2] sched: Minimize the idle cpu selection race window.

On Thu, Nov 23, 2017 at 02:13:01PM +0100, Mike Galbraith wrote: > On Thu, 2017-11-23 at 11:52 +0100, Uladzislau Rezki wrote: > > Hello, Atish, Peter, all. > > > > I have a question about if a task's nr_cpus_allowed is 1. > > In that scenario we do not call select_

Re: [PATCH RFC 1/2] sched: Minimize the idle cpu selection race window.

RE_PER_CPU(struct sched_domain *, sd_numa); DECLARE_PER_CPU(struct sched_domain *, sd_asym); +DECLARE_PER_CPU(int, claim_wakeup); struct sched_group_capacity { atomic_t ref; -- Uladzislau Rezki On Tue, Nov 21, 2017 at 11:23:18PM -0600, Atish Patra wrote: > Here are the results of sch

Re: [PATCH RFC 1/2] sched: Minimize the idle cpu selection race window.

On Tue, Nov 28, 2017 at 11:49:11AM +0100, Mike Galbraith wrote: > On Tue, 2017-11-28 at 10:34 +0100, Uladzislau Rezki wrote: > > On Fri, Nov 24, 2017 at 07:46:30PM +0100, Mike Galbraith wrote: > > > > > My view is you're barking up the wrong tree: you're making the idle

Re: [PATCH RFC 1/2] sched: Minimize the idle cpu selection race window.

On Wed, Nov 29, 2017 at 07:15:21PM +0100, Mike Galbraith wrote: > On Wed, 2017-11-29 at 11:41 +0100, Uladzislau Rezki wrote: > > On Tue, Nov 28, 2017 at 11:49:11AM +0100, Mike Galbraith wrote: > > > On Tue, 2017-11-28 at 10:34 +0100, Uladzislau Rezki wrote: > > > >

Re: [PATCH RFC 2/5] sched/fair: Skip frequency update if CPU about to idle

e can > make sense. > > Regarding the reduction of the number of OPP changes, will the > util_est feature provide the same amount of reduction by directly > providing the estimated max utilization ? > > Just to say that IMHO skipping or not OPP change at dequeue is a > policy decision and not a generic one > Indeed. Otherwise we may end up in a situation of handling corner cases in a scheduler when it comes to OPP updates. I also agree that it is up to policy to do update or not. -- Uladzislau Rezki

Re: [RFC v1] mm: add the preempt check into alloc_vmap_area()

On Fri, Mar 02, 2018 at 03:34:52PM -0800, Andrew Morton wrote: > On Tue, 27 Feb 2018 05:06:43 -0800 Matthew Wilcox <wi...@infradead.org> wrote: > > > On Tue, Feb 27, 2018 at 11:22:59AM +0100, Uladzislau Rezki (Sony) wrote: > > > During finding a suitable

Re: [RFC v1] mm: add the preempt check into alloc_vmap_area()

On Tue, Feb 27, 2018 at 05:06:43AM -0800, Matthew Wilcox wrote: > On Tue, Feb 27, 2018 at 11:22:59AM +0100, Uladzislau Rezki (Sony) wrote: > > During finding a suitable hole in the vmap_area_list > > there is an explicit rescheduling check for latency reduction. >

Re: [RFC PATCH 0/2] improve vmalloc allocation

On Fri, Oct 19, 2018 at 05:11:45PM -0700, Joel Fernandes wrote: > On Fri, Oct 19, 2018 at 07:35:36PM +0200, Uladzislau Rezki (Sony) wrote: > > Objective > > - > > Initiative of improving vmalloc allocator comes from getting many issues > > related to allo

Re: [RFC PATCH 0/2] improve vmalloc allocation

On Fri, Oct 19, 2018 at 10:44:39PM +, Roman Gushchin wrote: > On Fri, Oct 19, 2018 at 07:35:36PM +0200, Uladzislau Rezki (Sony) wrote: > > Objective > > - > > Initiative of improving vmalloc allocator comes from getting many issues > > related to allo

Re: [RFC PATCH 0/2] improve vmalloc allocation

On Mon, Oct 22, 2018 at 02:51:42PM +0200, Michal Hocko wrote: > Hi, > I haven't read through the implementation yet but I have say that I > really love this cover letter. It is clear on intetion, it covers design > from high level enough to start discussion and provides a very nice > testing

Re: [RFC PATCH 0/2] improve vmalloc allocation

On Tue, Oct 23, 2018 at 08:26:40AM -0700, Matthew Wilcox wrote: > On Tue, Oct 23, 2018 at 09:02:56AM -0600, Shuah Khan wrote: > > Hi Michal, > > > > On 10/23/2018 01:23 AM, Michal Hocko wrote: > > > Hi Shuah, > > > > > > On Mon 22-10-18 18:52:5

Re: [RFC PATCH 0/2] improve vmalloc allocation

Hi. On Wed, Oct 24, 2018 at 08:22:52AM +0200, Michal Hocko wrote: > On Tue 23-10-18 12:30:44, Joel Fernandes wrote: > > On Tue, Oct 23, 2018 at 11:13:36AM -0600, Shuah Khan wrote: > > > On 10/23/2018 11:05 AM, Michal Hocko wrote: > > > > On Tue 23-10-18 08:26:40, Matthew Wilcox wrote: > > > >> On

Re: [RFC PATCH 0/2] improve vmalloc allocation

On Wed, Oct 24, 2018 at 04:01:06PM -0700, Andrew Morton wrote: > On Fri, 19 Oct 2018 19:35:36 +0200 "Uladzislau Rezki (Sony)" > wrote: > > > improving vmalloc allocator > > It's about time ;) > > Are you aware of https://lwn.net/Articles/285341/ ? If

Re: [RFC PATCH 0/2] improve vmalloc allocation

On Thu, Oct 25, 2018 at 10:43:27AM +0200, Michal Hocko wrote: > On Wed 24-10-18 19:34:18, Uladzislau Rezki wrote: > > Hi. > > > > On Wed, Oct 24, 2018 at 08:22:52AM +0200, Michal Hocko wrote: > > > On Tue 23-10-18 12:30:44, Joel Fernandes wrote: > > > >

Re: [RFC PATCH 1/1] vmalloc: add test driver to analyse vmalloc allocator

On Tue, Nov 13, 2018 at 02:10:46PM -0800, Andrew Morton wrote: > On Tue, 13 Nov 2018 16:16:29 +0100 "Uladzislau Rezki (Sony)" > wrote: > > > This adds a new kernel module for analysis of vmalloc allocator. It is > > only enabled as a module. There are two

Re: [RFC v1] mm: add the preempt check into alloc_vmap_area()

On Tue, Feb 27, 2018 at 05:06:43AM -0800, Matthew Wilcox wrote: > On Tue, Feb 27, 2018 at 11:22:59AM +0100, Uladzislau Rezki (Sony) wrote: > > During finding a suitable hole in the vmap_area_list > > there is an explicit rescheduling check for latency reduction. >

Re: [RFC v1] sched/fair: search a task from the tail of the queue

On Mon, Aug 28, 2017 at 10:41 AM, Peter Zijlstra wrote: > On Fri, Aug 25, 2017 at 12:11:31AM +0200, Uladzislau Rezki (Sony) wrote: >> From: Uladzislau Rezki >> >> As a first step this patch makes cfs_tasks list as MRU one. >> It means, that when a next task is picke

Re: [PATCH RFC 1/2] sched: Minimize the idle cpu selection race window.

On Fri, Nov 24, 2017 at 07:46:30PM +0100, Mike Galbraith wrote: > On Fri, 2017-11-24 at 11:26 +0100, Uladzislau Rezki wrote: > > > > I guess there is misunderstanding here. The main goal is not to cover > > pinned case, for sure. I was thinking more about below poin

Re: [PATCH RFC 1/2] sched: Minimize the idle cpu selection race window.

On Tue, Nov 28, 2017 at 11:49:11AM +0100, Mike Galbraith wrote: > On Tue, 2017-11-28 at 10:34 +0100, Uladzislau Rezki wrote: > > On Fri, Nov 24, 2017 at 07:46:30PM +0100, Mike Galbraith wrote: > > > > > My view is you're barking up the wrong tree: you're making the idle

Re: [PATCH RFC 2/5] sched/fair: Skip frequency update if CPU about to idle

eduction of the number of OPP changes, will the > util_est feature provide the same amount of reduction by directly > providing the estimated max utilization ? > > Just to say that IMHO skipping or not OPP change at dequeue is a > policy decision and not a generic one > Indeed. Otherwise we may end up in a situation of handling corner cases in a scheduler when it comes to OPP updates. I also agree that it is up to policy to do update or not. -- Uladzislau Rezki

Re: [RFC][PATCH]: sched/fair: search a task from the tail of the queue

On Thu, Aug 24, 2017 at 7:46 PM, Peter Zijlstra wrote: > > On Thu, Aug 24, 2017 at 12:44:45PM +0200, Uladzislau Rezki (Sony) wrote: > > From: Uladzislau Rezki > > > > When a task is enqueued back from a physical CPU to the running > > list it is placed in th

Re: [RFC v1] sched/fair: search a task from the tail of the queue

On Mon, Aug 28, 2017 at 10:41:55AM +0200, Peter Zijlstra wrote: > On Fri, Aug 25, 2017 at 12:11:31AM +0200, Uladzislau Rezki (Sony) wrote: > > From: Uladzislau Rezki > > > > As a first step this patch makes cfs_tasks list as MRU one. > > It means, that when a

Re: [RFC v1] mm: add the preempt check into alloc_vmap_area()

On Fri, Mar 02, 2018 at 03:34:52PM -0800, Andrew Morton wrote: > On Tue, 27 Feb 2018 05:06:43 -0800 Matthew Wilcox wrote: > > > On Tue, Feb 27, 2018 at 11:22:59AM +0100, Uladzislau Rezki (Sony) wrote: > > > During finding a suitable hole in the vmap_area_list >

Re: [PATCH RFC 1/2] sched: Minimize the idle cpu selection race window.

RE_PER_CPU(struct sched_domain *, sd_numa); DECLARE_PER_CPU(struct sched_domain *, sd_asym); +DECLARE_PER_CPU(int, claim_wakeup); struct sched_group_capacity { atomic_t ref; -- Uladzislau Rezki On Tue, Nov 21, 2017 at 11:23:18PM -0600, Atish Patra wrote: > Here are the results of sch

Re: [PATCH RFC 1/2] sched: Minimize the idle cpu selection race window.

On Wed, Nov 29, 2017 at 07:15:21PM +0100, Mike Galbraith wrote: > On Wed, 2017-11-29 at 11:41 +0100, Uladzislau Rezki wrote: > > On Tue, Nov 28, 2017 at 11:49:11AM +0100, Mike Galbraith wrote: > > > On Tue, 2017-11-28 at 10:34 +0100, Uladzislau Rezki wrote: > > > >

Re: [PATCH RFC 1/2] sched: Minimize the idle cpu selection race window.

On Thu, Nov 23, 2017 at 02:13:01PM +0100, Mike Galbraith wrote: > On Thu, 2017-11-23 at 11:52 +0100, Uladzislau Rezki wrote: > > Hello, Atish, Peter, all. > > > > I have a question about if a task's nr_cpus_allowed is 1. > > In that scenario we do not call select_

Re: [PATCH 1/3] kvfree_rcu: Allocate a page for a single argument

On Wed, Jan 20, 2021 at 08:57:57PM +0100, Sebastian Andrzej Siewior wrote: > On 2021-01-20 17:21:46 [+0100], Uladzislau Rezki (Sony) wrote: > > For a single argument we can directly request a page from a caller > > context when a "carry page block" is run out of free spot

Re: [PATCH 1/3] kvfree_rcu: Allocate a page for a single argument

On Wed, Jan 20, 2021 at 01:54:03PM -0800, Paul E. McKenney wrote: > On Wed, Jan 20, 2021 at 08:57:57PM +0100, Sebastian Andrzej Siewior wrote: > > On 2021-01-20 17:21:46 [+0100], Uladzislau Rezki (Sony) wrote: > > > For a single argument we can directly request a page from a ca

Re: [PATCH] rcu: better document kfree_rcu()

riod. > -- > 2.29.2 > I think it is fair enough. I checked the "kernel-doc" and after this change it does not detect any violations which are in question. Tested-by: Uladzislau Rezki (Sony) -- Vlad Rezki

Re: [PATCH 1/3] kvfree_rcu: Allocate a page for a single argument

On Mon, Jan 25, 2021 at 04:39:43PM +0100, Michal Hocko wrote: > On Mon 25-01-21 15:31:50, Uladzislau Rezki wrote: > > > On Wed 20-01-21 17:21:46, Uladzislau Rezki (Sony) wrote: > > > > For a single argument we can directly request a page from a caller > > > &

Re: [PATCH 1/3] kvfree_rcu: Allocate a page for a single argument

> On Wed 20-01-21 17:21:46, Uladzislau Rezki (Sony) wrote: > > For a single argument we can directly request a page from a caller > > context when a "carry page block" is run out of free spots. Instead > > of hitting a slow path we can request an extra page by dem

Re: 回复: 回复: [PATCH 3/3] kvfree_rcu: use migrate_disable/enable()

> > > 发件人: Uladzislau Rezki > 发送时间: 2021年1月25日 5:57 > 收件人: Zhang, Qiang > 抄送: Uladzislau Rezki (Sony); LKML; RCU; Paul E . McKenney; Michael Ellerman; > Andrew Morton; Daniel Axtens; Frederic Weisbecker; Neeraj Upadhyay; Joel > F

Re: [PATCH] rcu: Release per-cpu krcp page cache when CPU going offline

Hello, Qiang, > On Thu, Jan 21, 2021 at 02:49:49PM +0800, qiang.zh...@windriver.com wrote: > > From: Zqiang > > > > If CPUs go offline, the corresponding krcp's page cache can > > not be use util the CPU come back online, or maybe the CPU > > will never go online again, this commit therefore

Re: 回复: [PATCH] rcu: Release per-cpu krcp page cache when CPU going offline

On Fri, Jan 22, 2021 at 01:44:36AM +, Zhang, Qiang wrote: > > > ____ > 发件人: Uladzislau Rezki > 发送时间: 2021年1月22日 4:26 > 收件人: Zhang, Qiang > 抄送: Paul E. McKenney; r...@vger.kernel.org; linux-kernel@vger.kernel.org; > ure...@gmail.c

Re: [PATCH 1/3] kvfree_rcu: Allocate a page for a single argument

> On 2021-01-21 13:38:34 [+0100], Uladzislau Rezki wrote: > > __get_free_page() returns "unsigned long" whereas a bnode is a pointer > > to kvfree_rcu_bulk_data struct, without a casting the compiler will > > emit a warning. > > Yes, learned about it,

Re: [PATCH 1/3] kvfree_rcu: Allocate a page for a single argument

On Thu, Jan 21, 2021 at 07:07:40AM -0800, Paul E. McKenney wrote: > On Thu, Jan 21, 2021 at 02:35:10PM +0100, Uladzislau Rezki wrote: > > On Wed, Jan 20, 2021 at 01:54:03PM -0800, Paul E. McKenney wrote: > > > On Wed, Jan 20, 2021 at 08:57:57PM +0100, Sebastian And

Re: kerneldoc warnings since commit 538fc2ee870a3 ("rcu: Introduce kfree_rcu() single-argument macro")

> On Tue, Jan 5, 2021 at 5:29 PM Uladzislau Rezki wrote: > > > > On Tue, Jan 05, 2021 at 06:56:59AM -0800, Paul E. McKenney wrote: > > > On Tue, Jan 05, 2021 at 02:14:41PM +0100, Uladzislau Rezki wrote: > > > > Dear, Lukas. > > > > > >

Re: [PATCH] mm/vmalloc.c: Fix potential memory leak

area->nr_pages = count; > + } > return area->addr; > } > EXPORT_SYMBOL(vmap); > -- > 2.19.1 > Reviewed-by: Uladzislau Rezki (Sony) -- Vlad Rezki

Re: 回复: 回复: [PATCH] rcu: Release per-cpu krcp page cache when CPU going offline

On Sun, Jan 24, 2021 at 02:21:07AM +, Zhang, Qiang wrote: > > > ____ > 发件人: Uladzislau Rezki > 发送时间: 2021年1月22日 22:31 > 收件人: Zhang, Qiang > 抄送: Uladzislau Rezki; Paul E. McKenney; r...@vger.kernel.org; > linux-kernel@vger.kernel.

Re: [RFC-PATCH 2/4] mm: Add __rcu_alloc_page_lockless() func.

On Fri, Oct 02, 2020 at 09:11:23AM +0200, Michal Hocko wrote: > On Thu 01-10-20 21:26:26, Uladzislau Rezki wrote: > > > > > > No, I meant going back to idea of new gfp flag, but adjust the > > > implementation in > > > the allocator (different from

Re: [RFC-PATCH 2/4] mm: Add __rcu_alloc_page_lockless() func.

On Fri, Oct 02, 2020 at 09:06:24AM +0100, Mel Gorman wrote: > On Thu, Oct 01, 2020 at 09:26:26PM +0200, Uladzislau Rezki wrote: > > > > > > No, I meant going back to idea of new gfp flag, but adjust the > > > implementation in > > > the allocator (dif

Re: [RFC-PATCH 2/4] mm: Add __rcu_alloc_page_lockless() func.

On Fri, Oct 02, 2020 at 11:05:07AM +0200, Michal Hocko wrote: > On Fri 02-10-20 09:50:14, Mel Gorman wrote: > > On Fri, Oct 02, 2020 at 09:11:23AM +0200, Michal Hocko wrote: > > > On Thu 01-10-20 21:26:26, Uladzislau Rezki wrote: > > > > > > > > > >

Re: [RFC-PATCH 2/4] mm: Add __rcu_alloc_page_lockless() func.

On Mon, Oct 05, 2020 at 05:41:00PM +0200, Michal Hocko wrote: > On Mon 05-10-20 17:08:01, Uladzislau Rezki wrote: > > On Fri, Oct 02, 2020 at 11:05:07AM +0200, Michal Hocko wrote: > > > On Fri 02-10-20 09:50:14, Mel Gorman wrote: > > > > On Fri, Oct 02, 2020 at 09:11:

Re: [RFC-PATCH 2/4] mm: Add __rcu_alloc_page_lockless() func.

On Wed, Oct 07, 2020 at 12:02:34PM +0200, Michal Hocko wrote: > On Wed 07-10-20 00:25:29, Uladzislau Rezki wrote: > > On Mon, Oct 05, 2020 at 05:41:00PM +0200, Michal Hocko wrote: > > > On Mon 05-10-20 17:08:01, Uladzislau Rezki wrote: > > > > On Fri, Oct 02, 2020 at

Re: [RFC-PROTOTYPE 1/1] mm: Add __GFP_FAST_TRY flag

On Tue, Aug 04, 2020 at 07:02:14PM +0200, Vlastimil Babka wrote: > On 8/3/20 6:30 PM, Uladzislau Rezki (Sony) wrote: > > Some background and kfree_rcu() > > === > > The pointers to be freed are stored in the per-cpu array to improve > > perfo

Re: [RFC-PROTOTYPE 1/1] mm: Add __GFP_FAST_TRY flag

On Tue, Aug 04, 2020 at 06:12:03PM +0100, Matthew Wilcox wrote: > On Tue, Aug 04, 2020 at 07:02:14PM +0200, Vlastimil Babka wrote: > > > 2) There was a proposal from Matthew Wilcox: > > > https://lkml.org/lkml/2020/7/31/1015 > > > > > > > > > On non-RT, we could make that lock a raw spinlock.

Re: [RFC-PROTOTYPE 1/1] mm: Add __GFP_FAST_TRY flag

On Tue, Aug 04, 2020 at 07:34:18PM +0200, Vlastimil Babka wrote: > On 8/4/20 7:12 PM, Matthew Wilcox wrote: > > On Tue, Aug 04, 2020 at 07:02:14PM +0200, Vlastimil Babka wrote: > >> > 2) There was a proposal from Matthew Wilcox: > >> > https://lkml.org/lkml/2020/7/31/1015 > >> > > >> > > >> >

Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag

> On Sun 09-08-20 22:43:53, Uladzislau Rezki (Sony) wrote: > [...] > > Limitations and concerns (Main part) > > > > The current memmory-allocation interface presents to following > > difficulties that this patch is designed to

Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag

On Mon, Aug 10, 2020 at 09:25:25PM +0200, Michal Hocko wrote: > On Mon 10-08-20 18:07:39, Uladzislau Rezki wrote: > > > On Sun 09-08-20 22:43:53, Uladzislau Rezki (Sony) wrote: > > > [...] > > > > Limitations and concerns (Main part) > > > > ===

Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag

On Tue, Aug 11, 2020 at 10:19:17AM +0200, Michal Hocko wrote: > On Mon 10-08-20 21:25:26, Michal Hocko wrote: > > On Mon 10-08-20 18:07:39, Uladzislau Rezki wrote: > [...] > > > The problem that i see is we can not use the page allocator from atomic > > &

Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag

On Tue, Aug 11, 2020 at 11:37:13AM +0200, Uladzislau Rezki wrote: > On Tue, Aug 11, 2020 at 10:19:17AM +0200, Michal Hocko wrote: > > On Mon 10-08-20 21:25:26, Michal Hocko wrote: > > > On Mon 10-08-20 18:07:39, Uladzislau Rezki wrote: > > [...] > > > > The

Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag

On Tue, Aug 11, 2020 at 12:28:18PM +0200, Michal Hocko wrote: > On Tue 11-08-20 11:42:51, Uladzislau Rezki wrote: > > On Tue, Aug 11, 2020 at 11:37:13AM +0200, Uladzislau Rezki wrote: > > > On Tue, Aug 11, 2020 at 10:19:17AM +0200, Michal Hocko wrote: > [...] > > &g

Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag

On Tue, Aug 11, 2020 at 12:21:24PM +0200, Michal Hocko wrote: > On Tue 11-08-20 11:18:07, Uladzislau Rezki wrote: > > On Mon, Aug 10, 2020 at 09:25:25PM +0200, Michal Hocko wrote: > > > On Mon 10-08-20 18:07:39, Uladzislau Rezki wrote: > > > > > On Sun 09-08-20

Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag

On Tue, Aug 11, 2020 at 12:26:49PM +0200, Michal Hocko wrote: > On Tue 11-08-20 11:37:13, Uladzislau Rezki wrote: > > On Tue, Aug 11, 2020 at 10:19:17AM +0200, Michal Hocko wrote: > > > On Mon 10-08-20 21:25:26, Michal Hocko wrote: > > > > On Mon 10-08-20 18

Re: [RFC-PATCH 2/4] mm: Add __rcu_alloc_page_lockless() func.

> > I look at it in scope of GFP_ATOMIC/GFP_NOWAIT issues, i.e. inability > > to provide a memory service for contexts which are not allowed to > > sleep, RCU is part of them. Both flags used to provide such ability > > before but not anymore. > > > > Do you agree with it? > > Yes this sucks.

Re: [PATCH] mm: clarify usage of GFP_ATOMIC in !preemptible contexts

mic reserves". > + * The current implementation doesn't support NMI and few other strict > + * non-preemptive contexts (e.g. raw_spin_lock). The same applies to > %GFP_NOWAIT. > * > * %GFP_KERNEL is typical for kernel-internal allocations. The caller > requires > * %ZONE_NORMAL or a lower zone for direct access but can direct reclaim. > -- > 2.28.0 > Reviewed-by: Uladzislau Rezki

Re: [RFC-PATCH 2/4] mm: Add __rcu_alloc_page_lockless() func.

On Tue, Sep 29, 2020 at 12:15:34PM +0200, Vlastimil Babka wrote: > On 9/18/20 9:48 PM, Uladzislau Rezki (Sony) wrote: > > Some background and kfree_rcu() > > === > > The pointers to be freed are stored in the per-cpu array to improve > > perfo

Re: [PATCH tip/core/rcu 14/15] rcu/tree: Allocate a page when caller is preemptible

> > > > What is the point of calling kmalloc for a PAGE_SIZE object? Wouldn't > > > using the page allocator directly be better? > > > > Well, you guys gave me considerable heat about abusing internal allocator > > interfaces, and kmalloc() and kfree() seem to be about as non-internal > > as you

Re: [RFC-PATCH 2/4] mm: Add __rcu_alloc_page_lockless() func.

On Wed, Sep 30, 2020 at 11:27:32AM +0200, Michal Hocko wrote: > On Tue 29-09-20 18:25:14, Uladzislau Rezki wrote: > > > > I look at it in scope of GFP_ATOMIC/GFP_NOWAIT issues, i.e. inability > > > > to provide a memory service for contexts which are not allowed to

Re: [RFC-PATCH 2/4] mm: Add __rcu_alloc_page_lockless() func.

On Wed, Sep 30, 2020 at 02:44:13PM +0200, Michal Hocko wrote: > On Wed 30-09-20 14:35:35, Uladzislau Rezki wrote: > > On Wed, Sep 30, 2020 at 11:27:32AM +0200, Michal Hocko wrote: > > > On Tue 29-09-20 18:25:14, Uladzislau Rezki wrote: > > > > > > I look at

Re: [RFC-PATCH 2/4] mm: Add __rcu_alloc_page_lockless() func.

On Wed, Sep 30, 2020 at 06:46:00PM +0200, Michal Hocko wrote: > On Wed 30-09-20 15:39:54, Uladzislau Rezki wrote: > > On Wed, Sep 30, 2020 at 02:44:13PM +0200, Michal Hocko wrote: > > > On Wed 30-09-20 14:35:35, Uladzislau Rezki wrote: > > > > On Wed, Sep 30, 2020 at

Re: [RFC-PATCH 2/4] mm: Add __rcu_alloc_page_lockless() func.

> > No, I meant going back to idea of new gfp flag, but adjust the implementation > in > the allocator (different from what you posted in previous version) so that it > only looks at the flag after it tries to allocate from pcplist and finds out > it's empty. So, no inventing of new page

Re: [RFC-PATCH 2/4] mm: Add __rcu_alloc_page_lockless() func.

On Wed, Sep 30, 2020 at 12:35:57PM +0200, Michal Hocko wrote: > On Wed 30-09-20 00:07:42, Uladzislau Rezki wrote: > [...] > > > > bool is_pcp_cache_empty(gfp_t gfp) > > { > > struct per_cpu_pages *pcp; > > struct zoneref *ref; > >

Re: [PATCH tip/core/rcu 14/15] rcu/tree: Allocate a page when caller is preemptible

6cee168ccf8688bb8b872478 > > Author: Paul E. McKenney > > Date: Wed Sep 30 16:16:39 2020 -0700 > > > > kvfree_rcu(): Switch from kmalloc/kfree to __get_free_page/free_page. > > > > The advantages of using kmalloc() and kfree() are a possible small

Re: [GIT PULL tip/core/rcu+preempt] Fix RT raw/non-raw lock ordering

up PREEMPT_COUNT leftovers > > > ARM: Cleanup PREEMPT_COUNT leftovers > > > xtensa: Cleanup PREEMPT_COUNT leftovers > > > drm/i915: Cleanup PREEMPT_COUNT leftovers > > > rcutorture: Cleanup PREEMPT_COUNT leftovers > > > preempt: Remove

Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag

On Wed, Aug 12, 2020 at 01:38:35PM +0200, Thomas Gleixner wrote: > Thomas Gleixner writes: > > Thomas Gleixner writes: > >> Michal Hocko writes: > >>> zone->lock should be held for a very limited amount of time. > >> > >> Emphasis on should. free_pcppages_bulk() can hold it for quite some time

Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag

On Thu, Aug 13, 2020 at 09:50:27AM +0200, Michal Hocko wrote: > On Wed 12-08-20 02:13:25, Thomas Gleixner wrote: > [...] > > I can understand your rationale and what you are trying to solve. So, if > > we can actually have a distinct GFP variant: > > > >

Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag

Hello, Michal. > > On Wed 12-08-20 02:13:25, Thomas Gleixner wrote: > > [...] > > > I can understand your rationale and what you are trying to solve. So, if > > > we can actually have a distinct GFP variant: > > > > > > GFP_I_ABSOLUTELY_HAVE_TO_DO_THAT_AND_I_KNOW_IT_CAN_FAIL_EARLY > > > >

Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag

On Thu, Aug 13, 2020 at 03:41:39PM +0200, Michal Hocko wrote: > On Thu 13-08-20 15:29:31, Uladzislau Rezki wrote: > [...] > > I was a bit out of focus and did not mention about one thing. Identifying > > the context > > type using preemtable() primitives looks a bit

Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag

> On Thu 13-08-20 08:41:59, Paul E. McKenney wrote: > > On Thu, Aug 13, 2020 at 04:53:35PM +0200, Michal Hocko wrote: > > > On Thu 13-08-20 16:34:57, Thomas Gleixner wrote: > > > > Michal Hocko writes: > > > > > On Thu 13-08-20 15:22:00, Thomas Gleixner wrote: > > > > >> It basically requires to

Re: [PATCH 4/4] rcu/tree: Use schedule_delayed_work() instead of WQ_HIGHPRI queue

On Sun, Sep 20, 2020 at 08:06:38AM -0700, Paul E. McKenney wrote: > On Fri, Sep 18, 2020 at 09:48:17PM +0200, Uladzislau Rezki (Sony) wrote: > > Recently the separate worker thread has been introduced to > > maintain the local page cache from the regular kernel context, > >

Re: [RFC-PATCH 2/4] mm: Add __rcu_alloc_page_lockless() func.

Hello, Michal. > > > > Yes, I do well remember that you are unhappy with this approach. > > Unfortunately, thus far, there is no solution that makes all developers > > happy. You might be glad to hear that we are also looking into other > > solutions, each of which makes some other developers

Re: [PATCH 1/2] rcu-tasks: move RCU-tasks initialization out of core_initcall()

>> API in early_initcall() callbacks. > >> > >> Fixes: 36dadef23fcc ("kprobes: Init kprobes in early_initcall") > >> Signed-off-by: Uladzislau Rezki (Sony) > > Tested-by: Daniel Axtens > Thank you for checking it! > >> --- > >> incl

Re: Energy-efficiency options within RCU

Hello, Paul. [Dropping CC] > Hello, Joel, > > In case you are -seriously- interested... ;-) > > Thanx, Paul > > rcu_nocbs= > > Adding a CPU to this list offloads RCU callback invocation from > that CPU's softirq handler to a kthread.

Re: [PATCH] mm/vmalloc: Fix unlock order in s_stop()

or example when there are multiple heavy readers of /proc/vmallocinfo, i think, it make sense to implement RCU safe lists iteration and get rid of both locks. As for the patch: Reviewed-by: Uladzislau Rezki (Sony) Thanks! -- Vlad Rezki

Re: [PATCH v2 sl-b 3/5] mm: Make mem_dump_obj() handle vmalloc() memory

On Tue, Dec 08, 2020 at 05:13:01PM -0800, paul...@kernel.org wrote: > From: "Paul E. McKenney" > > This commit adds vmalloc() support to mem_dump_obj(). Note that the > vmalloc_dump_obj() function combines the checking and dumping, in > contrast with the split between kmem_valid_obj() and

Re: [PATCH v2 sl-b 3/5] mm: Make mem_dump_obj() handle vmalloc() memory

On Wed, Dec 09, 2020 at 06:51:20PM +0100, Vlastimil Babka wrote: > On 12/9/20 2:13 AM, paul...@kernel.org wrote: > > From: "Paul E. McKenney" > > > > This commit adds vmalloc() support to mem_dump_obj(). Note that the > > vmalloc_dump_obj() function combines the checking and dumping, in > >

Re: [PATCH v2 sl-b 3/5] mm: Make mem_dump_obj() handle vmalloc() memory

On Wed, Dec 09, 2020 at 11:42:39AM -0800, Paul E. McKenney wrote: > On Wed, Dec 09, 2020 at 08:36:37PM +0100, Uladzislau Rezki wrote: > > On Tue, Dec 08, 2020 at 05:13:01PM -0800, paul...@kernel.org wrote: > > > From: "Paul E. McKenney" > > > >

Re: [PATCH 1/2] rcu-tasks: move RCU-tasks initialization out of core_initcall()

t;kprobes: Init kprobes in early_initcall") > Signed-off-by: Uladzislau Rezki (Sony) > --- > include/linux/rcupdate.h | 6 ++ > init/main.c | 1 + > kernel/rcu/tasks.h | 26 ++ > 3 files changed, 29 insertions(+), 4 deletion

Re: [PATCH 1/2] rcu-tasks: move RCU-tasks initialization out of core_initcall()

On Wed, Dec 09, 2020 at 07:26:13PM -0800, Paul E. McKenney wrote: > On Wed, Dec 09, 2020 at 09:27:31PM +0100, Uladzislau Rezki (Sony) wrote: > > Initialize the RCU-tasks earlier, before *_initcall() callbacks are > > invoked. Do it after the workqueue subsytem is up and running. Th

Re: [PATCH 2/2] rcu-tasks: add RCU-tasks self tests

On Mon, Dec 21, 2020 at 09:18:05AM -0800, Paul E. McKenney wrote: > On Mon, Dec 21, 2020 at 04:38:09PM +0100, Uladzislau Rezki wrote: > > On Wed, Dec 16, 2020 at 03:29:55PM -0800, Paul E. McKenney wrote: > > > On Wed, Dec 16, 2020 at 04:49:59PM +0100, Ulad

  1   2   3   4   5   6   7   >