[PATCH] RCU: Remove have_rcu_nocb_mask from tree_plugin.h

hex filename 130503907852438 145434083544623621cdddc vmlinux Signed-off-by: Rakib Mullick <rakib.mull...@gmail.com> Cc: "Paul E. McKenney" <paul...@linux.vnet.ibm.com> Cc: Josh Triplett <j...@joshtriplett.org> Cc: Steven Rostedt <rost...@goo

[PATCH] RCU: Remove have_rcu_nocb_mask from tree_plugin.h

hex filename 130503907852438 145434083544623621cdddc vmlinux Signed-off-by: Rakib Mullick Cc: "Paul E. McKenney" Cc: Josh Triplett Cc: Steven Rostedt Cc: Mathieu Desnoyers Cc: Lai Jiangshan --- Patch applied on top of linus's tree (commit cf9b0772f2e41).

Re: [PATCH] lib: Avoid redundant sizeof checking in __bitmap_weight() calculation.

On Tue, Nov 14, 2017 at 1:23 PM, Rasmus Villemoes wrote: > > hint: sizeof() very rarely evaluates to zero... So this is the same as > "is32 = 1". So the patch as-is is broken (and may explain the 1-byte > delta in vmlinux). But even if this condition is fixed, the patch

Re: [PATCH] lib: Avoid redundant sizeof checking in __bitmap_weight() calculation.

On Tue, Nov 14, 2017 at 1:23 PM, Rasmus Villemoes wrote: > > hint: sizeof() very rarely evaluates to zero... So this is the same as > "is32 = 1". So the patch as-is is broken (and may explain the 1-byte > delta in vmlinux). But even if this condition is fixed, the patch > doesn't change anything,

[PATCH] lib: Avoid redundant sizeof checking in __bitmap_weight() calculation.

bss dec hex filename 129013317798930 1454181635242077219c05d vmlinux Signed-off-by: Rakib Mullick <rakib.mull...@gmail.com> Cc: Andrew Morton <a...@linux-foundation.org> Cc: Rasmus Villemoes <li...@rasmusvillemoes.dk> Cc: Matthew Wilcox <m

[PATCH] lib: Avoid redundant sizeof checking in __bitmap_weight() calculation.

bss dec hex filename 129013317798930 1454181635242077219c05d vmlinux Signed-off-by: Rakib Mullick Cc: Andrew Morton Cc: Rasmus Villemoes Cc: Matthew Wilcox Cc: Yury Norov Cc: Mauro Carvalho Chehab --- Patch was created against torvald's tree (commit

Re: [PATCH] Documentation, fix module-signing file reference.

Ping! Anyone care to take this trivial fix? On Tue, Oct 31, 2017 at 8:39 PM, Rakib Mullick <rakib.mull...@gmail.com> wrote: > Kconfig reference for module-signing.txt file needs to > be replaced with admin-guide/module-signing.rst. > > Signed-off-by: Rakib Mullick <ra

Re: [PATCH] Documentation, fix module-signing file reference.

Ping! Anyone care to take this trivial fix? On Tue, Oct 31, 2017 at 8:39 PM, Rakib Mullick wrote: > Kconfig reference for module-signing.txt file needs to > be replaced with admin-guide/module-signing.rst. > > Signed-off-by: Rakib Mullick > --- > init/Kconfig | 2 +- &g

[tip:irq/core] irq/core: Fix boot crash when the irqaffinity= boot parameter is passed on CPUMASK_OFFSTACK=y kernels(v1)

Commit-ID: 10d94ff4d558b96bfc4f55bb0051ae4d938246fe Gitweb: https://git.kernel.org/tip/10d94ff4d558b96bfc4f55bb0051ae4d938246fe Author: Rakib Mullick <rakib.mull...@gmail.com> AuthorDate: Wed, 1 Nov 2017 10:14:51 +0600 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Wed

[tip:irq/core] irq/core: Fix boot crash when the irqaffinity= boot parameter is passed on CPUMASK_OFFSTACK=y kernels(v1)

Commit-ID: 10d94ff4d558b96bfc4f55bb0051ae4d938246fe Gitweb: https://git.kernel.org/tip/10d94ff4d558b96bfc4f55bb0051ae4d938246fe Author: Rakib Mullick AuthorDate: Wed, 1 Nov 2017 10:14:51 +0600 Committer: Ingo Molnar CommitDate: Wed, 1 Nov 2017 09:56:39 +0100 irq/core: Fix boot crash

Re: [PATCH] [irq] Fix boot failure when irqaffinity is passed.

On Tue, Oct 31, 2017 at 5:29 PM, Ingo Molnar wrote: > > > Not applied, because this patch causes the following build warning: > > kernel/irq/irqdesc.c:43:6: warning: the address of ‘irq_default_affinity’ > will always evaluate as ‘true’ [-Waddress] > Ah, sorry I didn't look

Re: [PATCH] [irq] Fix boot failure when irqaffinity is passed.

On Tue, Oct 31, 2017 at 5:29 PM, Ingo Molnar wrote: > > > Not applied, because this patch causes the following build warning: > > kernel/irq/irqdesc.c:43:6: warning: the address of ‘irq_default_affinity’ > will always evaluate as ‘true’ [-Waddress] > Ah, sorry I didn't look into the build log.

[PATCH] irq/core: Fix boot crash when the irqaffinity= boot parameter is passed on CPUMASK_OFFSTACK=y kernels(v1)

at it: in init_irq_default_affinity() remove an unnecessary #ifdef. Change since v0: * Fix build warning. Signed-off-by: Rakib Mullick <rakib.mull...@gmail.com> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Linus Torvalds <torva...@linux-foundation.org> Cc: Peter Zijlstra <pet...@infr

[PATCH] irq/core: Fix boot crash when the irqaffinity= boot parameter is passed on CPUMASK_OFFSTACK=y kernels(v1)

at it: in init_irq_default_affinity() remove an unnecessary #ifdef. Change since v0: * Fix build warning. Signed-off-by: Rakib Mullick Cc: Thomas Gleixner Cc: Linus Torvalds Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20171026045800.27087-1-rakib.mull...@gmail.com Signed-off-by: Ingo Molnar

[PATCH] Documentation, fix module-signing file reference.

Kconfig reference for module-signing.txt file needs to be replaced with admin-guide/module-signing.rst. Signed-off-by: Rakib Mullick <rakib.mull...@gmail.com> --- init/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/init/Kconfig b/init/Kconfig index 3c1faaa..1

[PATCH] Documentation, fix module-signing file reference.

Kconfig reference for module-signing.txt file needs to be replaced with admin-guide/module-signing.rst. Signed-off-by: Rakib Mullick --- init/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/init/Kconfig b/init/Kconfig index 3c1faaa..1b5e786 100644 --- a/init/Kconfig

[PATCH] [irq] Fix boot failure when irqaffinity is passed.

, these ifdef conditions are handled at defination site. Signed-off-by: Rakib Mullick <rakib.mull...@gmail.com> --- kernel/irq/irqdesc.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c index 982a357..db6380d 100644 --- a/kern

[PATCH] [irq] Fix boot failure when irqaffinity is passed.

, these ifdef conditions are handled at defination site. Signed-off-by: Rakib Mullick --- kernel/irq/irqdesc.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c index 982a357..db6380d 100644 --- a/kernel/irq/irqdesc.c +++ b/kernel/irq

[tip:sched/core] sched/isolcpus: Fix "isolcpus=" boot parameter handling when !CONFIG_CPUMASK_OFFSTACK

Commit-ID: e22cdc3fc5991956146b9856d36b4971fe54dcd6 Gitweb: https://git.kernel.org/tip/e22cdc3fc5991956146b9856d36b4971fe54dcd6 Author: Rakib Mullick <rakib.mull...@gmail.com> AuthorDate: Mon, 23 Oct 2017 19:01:54 +0600 Committer: Ingo Molnar <mi...@kernel.org> CommitDate:

[tip:sched/core] sched/isolcpus: Fix "isolcpus=" boot parameter handling when !CONFIG_CPUMASK_OFFSTACK

Commit-ID: e22cdc3fc5991956146b9856d36b4971fe54dcd6 Gitweb: https://git.kernel.org/tip/e22cdc3fc5991956146b9856d36b4971fe54dcd6 Author: Rakib Mullick AuthorDate: Mon, 23 Oct 2017 19:01:54 +0600 Committer: Ingo Molnar CommitDate: Tue, 24 Oct 2017 11:47:25 +0200 sched/isolcpus: Fix

[PATCH] Fix isocpus's param handling when CPUMASK_OFFSTACK=n.

> On Mon, Oct 23, 2017 at 5:50 PM, Ingo Molnar <mi...@kernel.org> wrote: > >> * Rakib Mullick <rakib.mull...@gmail.com> wrote: >> +/** >> + * cpumask_last - get the last cpu in a cpumask > > Please capitalize 'CPU' properly in docu

[PATCH] Fix isocpus's param handling when CPUMASK_OFFSTACK=n.

> On Mon, Oct 23, 2017 at 5:50 PM, Ingo Molnar wrote: > >> * Rakib Mullick wrote: >> +/** >> + * cpumask_last - get the last cpu in a cpumask > > Please capitalize 'CPU' properly in documentation. > OK. >> + int ret, lastcpu; >> >

[PATCH] Fix isocpus's param handling when CPUMASK_OFFSTACK=n.

> *On Fri, Oct 20, 2017 at 2:49 PM, Ingo Molnar <mi...@kernel.org> wrote: > >> Rakib Mullick <rakib.mull...@gmail.com> wrote: >> include/linux/cpumask.h | 16 >> kernel/sched/topology.c | 8 +--- >> 2 files changed, 21 ins

[PATCH] Fix isocpus's param handling when CPUMASK_OFFSTACK=n.

> *On Fri, Oct 20, 2017 at 2:49 PM, Ingo Molnar wrote: > >> Rakib Mullick wrote: >> include/linux/cpumask.h | 16 >> kernel/sched/topology.c | 8 +--- >> 2 files changed, 21 insertions(+), 3 deletions(-) > > What kernel is this agai

[PATCH] Fix isocpus's param handling when CPUMASK_OFFSTACK=n.

this issue by effectively find out the last cpu of the passed isolcpus list and checking it with nr_cpu_ids. Also, fixes the error message where the nr_cpu_ids should be nr_cpu_ids-1, since the cpu numbering starts from 0. Signed-off-by: Rakib Mullick <rakib.mull...@gmail.com> --- include

[PATCH] Fix isocpus's param handling when CPUMASK_OFFSTACK=n.

this issue by effectively find out the last cpu of the passed isolcpus list and checking it with nr_cpu_ids. Also, fixes the error message where the nr_cpu_ids should be nr_cpu_ids-1, since the cpu numbering starts from 0. Signed-off-by: Rakib Mullick --- include/linux/cpumask.h | 16

[PATCH] Remove cpuset_update_active_cpus()'s parameter.

In cpuset_update_active_cpus(), cpu_online isn't used anymore. Remove it. Signed-off-by: Rakib Mullick<rakib.mull...@gmail.com> --- include/linux/cpuset.h | 4 ++-- kernel/cgroup/cpuset.c | 2 +- kernel/sched/core.c| 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff

[PATCH] Remove cpuset_update_active_cpus()'s parameter.

In cpuset_update_active_cpus(), cpu_online isn't used anymore. Remove it. Signed-off-by: Rakib Mullick --- include/linux/cpuset.h | 4 ++-- kernel/cgroup/cpuset.c | 2 +- kernel/sched/core.c| 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/include/linux/cpuset.h b

[ANNOUNCE] BLD-3.18 release.

7-07-01 Group scheduling enhancements by Srivatsa Vaddagiri * 2007-11-29 RT balancing improvements by Steven Rostedt, Gregory Haskins, * Thomas Gleixner, Mike Kravetz + * 2012-Feb The Barbershop Load Distribution (BLD) algorithm - an alternate + *

[ANNOUNCE] BLD-3.18 release.

by Steven Rostedt, Gregory Haskins, * Thomas Gleixner, Mike Kravetz + * 2012-Feb The Barbershop Load Distribution (BLD) algorithm - an alternate + * CPU load distribution technique for kernel scheduler by Rakib Mullick. */ #include linux/mm.h @@ -86,6 +88,7

Re: [ANNOUNCE] BLD-3.17 release.

On 10/14/14, Mike Galbraith wrote: > On Mon, 2014-10-13 at 21:14 +0600, Rakib Mullick wrote: > >> Okay. From the numbers above it's apparent that BLD isn't doing good, >> atleast for the >> kind of system that you have been using. I didn't had a chance to ran >> it

Re: [ANNOUNCE] BLD-3.17 release.

On 10/14/14, Mike Galbraith umgwanakikb...@gmail.com wrote: On Mon, 2014-10-13 at 21:14 +0600, Rakib Mullick wrote: Okay. From the numbers above it's apparent that BLD isn't doing good, atleast for the kind of system that you have been using. I didn't had a chance to ran it on any kind

Re: [ANNOUNCE] BLD-3.17 release.

On 10/13/14, Mike Galbraith wrote: > On Sat, 2014-10-11 at 12:20 +0600, Rakib Mullick wrote: >> BLD (The Barbershop Load Distribution Algorithm) patch for Linux 3.17 > > I had a curiosity attack, played with it a little. > Thanks for showing your interest! > My l

Re: [ANNOUNCE] BLD-3.17 release.

On 10/13/14, Mike Galbraith umgwanakikb...@gmail.com wrote: On Sat, 2014-10-11 at 12:20 +0600, Rakib Mullick wrote: BLD (The Barbershop Load Distribution Algorithm) patch for Linux 3.17 I had a curiosity attack, played with it a little. Thanks for showing your interest! My little Q6600 box

[ANNOUNCE] BLD-3.17 release.

-by: Rakib Mullick --- diff --git a/init/Kconfig b/init/Kconfig index 80a6907..65319c6 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -36,6 +36,15 @@ config BROKEN_ON_SMP depends on BROKEN || !SMP default y +config BLD + bool "An alternate CPU load distribution tech

[ANNOUNCE] BLD-3.17 release.

-by: Rakib Mullick rakib.mull...@gmail.com --- diff --git a/init/Kconfig b/init/Kconfig index 80a6907..65319c6 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -36,6 +36,15 @@ config BROKEN_ON_SMP depends on BROKEN || !SMP default y +config BLD + bool An alternate CPU load

[PATCH] cpuidle: Minor optimization in cpuidle governor finding.

r name length we can determine whether to call strnicmp() i.e a shortcut. Signed-off-by: Rakib Mullick --- diff --git a/drivers/cpuidle/governor.c b/drivers/cpuidle/governor.c index ca89412..f601cc5 100644 --- a/drivers/cpuidle/governor.c +++ b/drivers/cpuidle/governor.c @@ -20,16 +20,21 @@ str

[PATCH] cpuidle: Minor optimization in cpuidle governor finding.

whether to call strnicmp() i.e a shortcut. Signed-off-by: Rakib Mullick rakib.mull...@gmail.com --- diff --git a/drivers/cpuidle/governor.c b/drivers/cpuidle/governor.c index ca89412..f601cc5 100644 --- a/drivers/cpuidle/governor.c +++ b/drivers/cpuidle/governor.c @@ -20,16 +20,21 @@ struct

[PATCH] x86: Avoid showing repetitive message from intel_init_thermal().

it only once and no need to get the same message at every time system resumes. So, limit showing this message only at system boot time by avoid showing at system resume and reduce abusing kernel log buffer. Signed-off-by: Rakib Mullick --- diff --git a/arch/x86/kernel/cpu/mcheck/therm_throt.c b

ANNOUNCE: BLD-3.16 release.

should run okay (tested personally) , but, yes it can break your boxes too. I'm looking forward to get some feedback, to keep further development up and going. (This patch is made for kernel version 3.16.) Thanks, Rakib --- Signed-off-by: Rakib Mullick diff --git a/init/Kconfig b/init/Kconfig

ANNOUNCE: BLD-3.16 release.

should run okay (tested personally) , but, yes it can break your boxes too. I'm looking forward to get some feedback, to keep further development up and going. (This patch is made for kernel version 3.16.) Thanks, Rakib --- Signed-off-by: Rakib Mullick rakib.mull...@gmail.com diff --git a/init

Re: Do we really need curr_target in signal_struct ?

On Mon, Feb 3, 2014 at 10:39 PM, Oleg Nesterov wrote: > On 02/02, Rakib Mullick wrote: > >> > As I already said it caches the last wants_signal(t) thread? >> Yes, you said. But, gets messed up at exit path, not useful everytime. > > Yes. > >> If

Re: Do we really need curr_target in signal_struct ?

On Mon, Feb 3, 2014 at 10:39 PM, Oleg Nesterov o...@redhat.com wrote: On 02/02, Rakib Mullick wrote: As I already said it caches the last wants_signal(t) thread? Yes, you said. But, gets messed up at exit path, not useful everytime. Yes. If fails, p gets checked twice. Yes

Re: Do we really need curr_target in signal_struct ?

On Sat, Feb 1, 2014 at 10:51 PM, Oleg Nesterov wrote: > On 02/01, Rakib Mullick wrote: >> >> On Thu, Jan 30, 2014 at 1:02 PM, Rakib Mullick >> wrote: >> > On Thu, Jan 30, 2014 at 12:32 AM, Oleg Nesterov wrote: >> >> On 01/29, Rakib Mullick wrote:

Re: Do we really need curr_target in signal_struct ?

On Sat, Feb 1, 2014 at 10:51 PM, Oleg Nesterov o...@redhat.com wrote: On 02/01, Rakib Mullick wrote: On Thu, Jan 30, 2014 at 1:02 PM, Rakib Mullick rakib.mull...@gmail.com wrote: On Thu, Jan 30, 2014 at 12:32 AM, Oleg Nesterov o...@redhat.com wrote: On 01/29, Rakib Mullick wrote

Re: Do we really need curr_target in signal_struct ?

On Thu, Jan 30, 2014 at 1:02 PM, Rakib Mullick wrote: > On Thu, Jan 30, 2014 at 12:32 AM, Oleg Nesterov wrote: >> On 01/29, Rakib Mullick wrote: > >>> Are you thinking that , since things are not broken, then we shouldn't >>> try to do anything? >> >> Hm

Re: Do we really need curr_target in signal_struct ?

On Thu, Jan 30, 2014 at 1:02 PM, Rakib Mullick rakib.mull...@gmail.com wrote: On Thu, Jan 30, 2014 at 12:32 AM, Oleg Nesterov o...@redhat.com wrote: On 01/29, Rakib Mullick wrote: Are you thinking that , since things are not broken, then we shouldn't try to do anything? Hmm. No. I am

Re: Do we really need curr_target in signal_struct ?

On Thu, Jan 30, 2014 at 12:32 AM, Oleg Nesterov wrote: > On 01/29, Rakib Mullick wrote: >> Are you thinking that , since things are not broken, then we shouldn't >> try to do anything? > > Hmm. No. > > I am thinking that, since you misunderstood the purpose of ->cu

Re: Do we really need curr_target in signal_struct ?

On Wed, Jan 29, 2014 at 8:55 PM, Oleg Nesterov wrote: > On 01/29, Rakib Mullick wrote: >> >> On Tue, Jan 28, 2014 at 10:43 PM, Oleg Nesterov wrote: >> > >> AFAIU, ->current_target is only a loop breaker to avoid infinite loop, > > No. It caches the last re

Re: Do we really need curr_target in signal_struct ?

On Wed, Jan 29, 2014 at 8:55 PM, Oleg Nesterov o...@redhat.com wrote: On 01/29, Rakib Mullick wrote: On Tue, Jan 28, 2014 at 10:43 PM, Oleg Nesterov o...@redhat.com wrote: AFAIU, -current_target is only a loop breaker to avoid infinite loop, No. It caches the last result of find a thread

Re: Do we really need curr_target in signal_struct ?

On Thu, Jan 30, 2014 at 12:32 AM, Oleg Nesterov o...@redhat.com wrote: On 01/29, Rakib Mullick wrote: Are you thinking that , since things are not broken, then we shouldn't try to do anything? Hmm. No. I am thinking that, since you misunderstood the purpose of -curr_target, I should

Re: Do we really need curr_target in signal_struct ?

On Wed, Jan 29, 2014 at 10:09 AM, Rakib Mullick wrote: > On Tue, Jan 28, 2014 at 10:43 PM, Oleg Nesterov wrote: >> On 01/28, Rakib Mullick wrote: >> >> You could simply do while_each_thread(p, t) to find a thread which >> wants_signal(..). >> > Yes, wh

Re: Do we really need curr_target in signal_struct ?

On Tue, Jan 28, 2014 at 10:43 PM, Oleg Nesterov wrote: > On 01/28, Rakib Mullick wrote: > > You could simply do while_each_thread(p, t) to find a thread which > wants_signal(..). > Yes, while_each_thread() is much nicer than get_nr_thread(), thanks for the pointer. > But I g

Do we really need curr_target in signal_struct ?

I was wondering what might be the possible use of curr_target in signal_struct (atleast, it's not doing what it's comment says). Also, I'm not seeing any real use of it except in kernel/signal.c::complete_signal() where it's use as loop breaking condition in thread's list traversing. As an

Do we really need curr_target in signal_struct ?

I was wondering what might be the possible use of curr_target in signal_struct (atleast, it's not doing what it's comment says). Also, I'm not seeing any real use of it except in kernel/signal.c::complete_signal() where it's use as loop breaking condition in thread's list traversing. As an

Re: Do we really need curr_target in signal_struct ?

On Tue, Jan 28, 2014 at 10:43 PM, Oleg Nesterov o...@redhat.com wrote: On 01/28, Rakib Mullick wrote: You could simply do while_each_thread(p, t) to find a thread which wants_signal(..). Yes, while_each_thread() is much nicer than get_nr_thread(), thanks for the pointer. But I guess

Re: Do we really need curr_target in signal_struct ?

On Wed, Jan 29, 2014 at 10:09 AM, Rakib Mullick rakib.mull...@gmail.com wrote: On Tue, Jan 28, 2014 at 10:43 PM, Oleg Nesterov o...@redhat.com wrote: On 01/28, Rakib Mullick wrote: You could simply do while_each_thread(p, t) to find a thread which wants_signal(..). Yes, while_each_thread

Re: [PATCH v2] sched: update_top_cache_domain only at the times of building sched domain.

On Wed, Jul 24, 2013 at 2:34 PM, Michael Wang wrote: > On 07/24/2013 04:01 PM, Rakib Mullick wrote: >> On Wed, Jul 24, 2013 at 9:26 AM, Michael Wang >> wrote: >>> Hi, Rakib >>> >>> On 07/24/2013 01:42 AM, Rakib Mullick wrote: >>>> Currently,

Re: [PATCH v2] sched: update_top_cache_domain only at the times of building sched domain.

On Wed, Jul 24, 2013 at 9:26 AM, Michael Wang wrote: > Hi, Rakib > > On 07/24/2013 01:42 AM, Rakib Mullick wrote: >> Currently, update_top_cache_domain() is called whenever schedule domain is >> built or destroyed. But, the following >> callpath shows that they're a

Re: [PATCH v2] sched: update_top_cache_domain only at the times of building sched domain.

On Wed, Jul 24, 2013 at 9:26 AM, Michael Wang wang...@linux.vnet.ibm.com wrote: Hi, Rakib On 07/24/2013 01:42 AM, Rakib Mullick wrote: Currently, update_top_cache_domain() is called whenever schedule domain is built or destroyed. But, the following callpath shows that they're at the same

Re: [PATCH v2] sched: update_top_cache_domain only at the times of building sched domain.

On Wed, Jul 24, 2013 at 2:34 PM, Michael Wang wang...@linux.vnet.ibm.com wrote: On 07/24/2013 04:01 PM, Rakib Mullick wrote: On Wed, Jul 24, 2013 at 9:26 AM, Michael Wang wang...@linux.vnet.ibm.com wrote: Hi, Rakib On 07/24/2013 01:42 AM, Rakib Mullick wrote: Currently

[PATCH v2] sched: update_top_cache_domain only at the times of building sched domain.

() update_top_cache_domain() Changes since v1: use sd to determine when to skip, courtesy PeterZ Signed-off-by: Rakib Mullick --- diff --git a/kernel/sched/core.c b/kernel/sched/core.c index b7c32cb..387fb66 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -5138,7 +5138,8

Re: [PATCH, RFC] sched: update_top_cache_domain only at the times of building sched domain.

On Tue, Jul 23, 2013 at 10:53 PM, Peter Zijlstra wrote: > On Tue, Jul 23, 2013 at 10:20:20PM +0600, Rakib Mullick wrote: > >> You mean using sd == NULL rather than using update_cache_domain variable ? > > Yes, note how: > > @@ -6109,7 +6110,7 @@ static void detach_dest

Re: [PATCH, RFC] sched: update_top_cache_domain only at the times of building sched domain.

On Tue, Jul 23, 2013 at 10:09 PM, Rakib Mullick wrote: > On Tue, Jul 23, 2013 at 9:47 PM, Peter Zijlstra wrote: >> On Tue, Jul 23, 2013 at 09:44:17PM +0600, Rakib Mullick wrote: >>> Currently, update_top_cache_domain() is called whenever schedule domain is >

Re: [PATCH, RFC] sched: update_top_cache_domain only at the times of building sched domain.

On Tue, Jul 23, 2013 at 9:47 PM, Peter Zijlstra wrote: > On Tue, Jul 23, 2013 at 09:44:17PM +0600, Rakib Mullick wrote: >> Currently, update_top_cache_domain() is called whenever schedule domain is >> built or destroyed. But, the following >> callpath shows that they're

[PATCH, RFC] sched: update_top_cache_domain only at the times of building sched domain.

() update_top_cache_domain() Signed-off-by: Rakib Mullick --- diff --git a/kernel/sched/core.c b/kernel/sched/core.c index b7c32cb..8c6fee4 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -5102,8 +5102,8 @@ static void update_top_cache_domain(int

[PATCH, RFC] sched: update_top_cache_domain only at the times of building sched domain.

() update_top_cache_domain() Signed-off-by: Rakib Mullick rakib.mull...@gmail.com --- diff --git a/kernel/sched/core.c b/kernel/sched/core.c index b7c32cb..8c6fee4 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -5102,8 +5102,8 @@ static void

Re: [PATCH, RFC] sched: update_top_cache_domain only at the times of building sched domain.

On Tue, Jul 23, 2013 at 9:47 PM, Peter Zijlstra pet...@infradead.org wrote: On Tue, Jul 23, 2013 at 09:44:17PM +0600, Rakib Mullick wrote: Currently, update_top_cache_domain() is called whenever schedule domain is built or destroyed. But, the following callpath shows that they're at the same

Re: [PATCH, RFC] sched: update_top_cache_domain only at the times of building sched domain.

On Tue, Jul 23, 2013 at 10:09 PM, Rakib Mullick rakib.mull...@gmail.com wrote: On Tue, Jul 23, 2013 at 9:47 PM, Peter Zijlstra pet...@infradead.org wrote: On Tue, Jul 23, 2013 at 09:44:17PM +0600, Rakib Mullick wrote: Currently, update_top_cache_domain() is called whenever schedule domain

Re: [PATCH, RFC] sched: update_top_cache_domain only at the times of building sched domain.

On Tue, Jul 23, 2013 at 10:53 PM, Peter Zijlstra pet...@infradead.org wrote: On Tue, Jul 23, 2013 at 10:20:20PM +0600, Rakib Mullick wrote: You mean using sd == NULL rather than using update_cache_domain variable ? Yes, note how: @@ -6109,7 +6110,7 @@ static void detach_destroy_domains

[PATCH v2] sched: update_top_cache_domain only at the times of building sched domain.

() update_top_cache_domain() Changes since v1: use sd to determine when to skip, courtesy PeterZ Signed-off-by: Rakib Mullick rakib.mull...@gmail.com --- diff --git a/kernel/sched/core.c b/kernel/sched/core.c index b7c32cb..387fb66 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -5138,7

Re: [RFC PATCH 0/2] sched: move content out of core files for load average

On Fri, Apr 19, 2013 at 2:25 PM, Ingo Molnar wrote: > > * Paul Gortmaker wrote: > >> On 13-04-18 07:14 AM, Peter Zijlstra wrote: >> > On Mon, 2013-04-15 at 11:33 +0200, Ingo Molnar wrote: >> >> * Paul Gortmaker wrote: >> >> >> >>> Recent activity has had a focus on moving functionally related

Re: [RFC PATCH 0/2] sched: move content out of core files for load average

On Fri, Apr 19, 2013 at 5:13 AM, Paul Gortmaker wrote: > [Re: [RFC PATCH 0/2] sched: move content out of core files for load average] > On 18/04/2013 (Thu 23:06) Rakib Mullick wrote: > >> On Thu, Apr 18, 2013 at 9:54 PM, Paul Gortmaker >> wrote: >> > On 13-04-18

Re: [RFC PATCH 0/2] sched: move content out of core files for load average

On Fri, Apr 19, 2013 at 5:13 AM, Paul Gortmaker paul.gortma...@windriver.com wrote: [Re: [RFC PATCH 0/2] sched: move content out of core files for load average] On 18/04/2013 (Thu 23:06) Rakib Mullick wrote: On Thu, Apr 18, 2013 at 9:54 PM, Paul Gortmaker paul.gortma...@windriver.com wrote

Re: [RFC PATCH 0/2] sched: move content out of core files for load average

On Fri, Apr 19, 2013 at 2:25 PM, Ingo Molnar mi...@kernel.org wrote: * Paul Gortmaker paul.gortma...@windriver.com wrote: On 13-04-18 07:14 AM, Peter Zijlstra wrote: On Mon, 2013-04-15 at 11:33 +0200, Ingo Molnar wrote: * Paul Gortmaker paul.gortma...@windriver.com wrote: Recent

Re: [RFC PATCH 0/2] sched: move content out of core files for load average

On Thu, Apr 18, 2013 at 9:54 PM, Paul Gortmaker wrote: > On 13-04-18 07:14 AM, Peter Zijlstra wrote: >> On Mon, 2013-04-15 at 11:33 +0200, Ingo Molnar wrote: >>> * Paul Gortmaker wrote: >>> Recent activity has had a focus on moving functionally related blocks of stuff out of

Re: [RFC PATCH 0/2] sched: move content out of core files for load average

On Thu, Apr 18, 2013 at 9:54 PM, Paul Gortmaker paul.gortma...@windriver.com wrote: On 13-04-18 07:14 AM, Peter Zijlstra wrote: On Mon, 2013-04-15 at 11:33 +0200, Ingo Molnar wrote: * Paul Gortmaker paul.gortma...@windriver.com wrote: Recent activity has had a focus on moving functionally

Re: [RFC PATCH 0/2] sched: move content out of core files for load average

On Sat, Apr 13, 2013 at 6:04 AM, Paul Gortmaker wrote: > Recent activity has had a focus on moving functionally related blocks of stuff > out of sched/core.c into stand-alone files. The code relating to load average > calculations has grown significantly enough recently to warrant placing it in

Re: [RFC PATCH 0/2] sched: move content out of core files for load average

On Sat, Apr 13, 2013 at 6:04 AM, Paul Gortmaker paul.gortma...@windriver.com wrote: Recent activity has had a focus on moving functionally related blocks of stuff out of sched/core.c into stand-alone files. The code relating to load average calculations has grown significantly enough recently

Re: [PATCH] auditsc: Use kzalloc instead of kmalloc+memset.

On Tue, Apr 9, 2013 at 3:43 AM, Andrew Morton wrote: > > Fair enough. I'd go futher... > > From: Andrew Morton > Subject: auditsc-use-kzalloc-instead-of-kmallocmemset-fix > > remove audit_set_context() altogether - fold it into its caller > > Cc: Al Viro > Cc: E

[QUESTION] loops_per_jiffy calculation from smp_callin().

Hello Ingo and all, In function arch/x86/kernel/smpboot.c::smp_callin(), we do a calibrate_delay(), the reason behind doing this is commented as follows: * Get our bogomips. * Update loops_per_jiffy in cpu_data. Previous call to * smp_store_cpu_info() stored a value

[QUESTION] loops_per_jiffy calculation from smp_callin().

Hello Ingo and all, In function arch/x86/kernel/smpboot.c::smp_callin(), we do a calibrate_delay(), the reason behind doing this is commented as follows: * Get our bogomips. * Update loops_per_jiffy in cpu_data. Previous call to * smp_store_cpu_info() stored a value

Re: [PATCH] auditsc: Use kzalloc instead of kmalloc+memset.

v...@zeniv.linux.org.uk Cc: Eric Paris epa...@redhat.com Cc: Rakib Mullick rakib.mull...@gmail.com Signed-off-by: Andrew Morton a...@linux-foundation.org --- kernel/auditsc.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff -puN kernel/auditsc.c~auditsc-use-kzalloc

[PATCH] auditsc: Use kzalloc instead of kmalloc+memset.

In function audit_alloc_context(), use kzalloc, instead of kmalloc+memset. Patch also renames audit_zero_context() to audit_set_context(), to represent it's inner workings properly. Signed-off-by: Rakib Mullick --- diff --git a/kernel/auditsc.c b/kernel/auditsc.c index a371f85..f5b6dc5

Re: old->umask copying without spin_lock, in copy_fs_struct()

On Sun, Apr 7, 2013 at 1:56 PM, Al Viro wrote: > On Sun, Apr 07, 2013 at 11:37:27AM +0600, Rakib Mullick wrote: >> Hello, >> >> In copy_fs_struct(), old->umask is assigned to fs->umask outside of >> spin_lock(>lock). Shouldn't it be inside spin_lock()? Since w

Re: old-umask copying without spin_lock, in copy_fs_struct()

On Sun, Apr 7, 2013 at 1:56 PM, Al Viro v...@zeniv.linux.org.uk wrote: On Sun, Apr 07, 2013 at 11:37:27AM +0600, Rakib Mullick wrote: Hello, In copy_fs_struct(), old-umask is assigned to fs-umask outside of spin_lock(old-lock). Shouldn't it be inside spin_lock()? Since we're dealing

[PATCH] auditsc: Use kzalloc instead of kmalloc+memset.

In function audit_alloc_context(), use kzalloc, instead of kmalloc+memset. Patch also renames audit_zero_context() to audit_set_context(), to represent it's inner workings properly. Signed-off-by: Rakib Mullick rakib.mull...@gmail.com --- diff --git a/kernel/auditsc.c b/kernel/auditsc.c

Re: [nsproxy] BUG: unable to handle kernel NULL pointer dereference at 0000000000000024

On Sat, Mar 9, 2013 at 10:48 PM, Rakib Mullick wrote: > On Sat, Mar 9, 2013 at 2:33 PM, Eric W. Biederman > wrote: >> Rakib Mullick writes: >> >>> On Fri, Mar 8, 2013 at 10:01 PM, Eric W. Biederman >>> wrote: >>>> >>>>

Re: [nsproxy] BUG: unable to handle kernel NULL pointer dereference at 0000000000000024

On Sat, Mar 9, 2013 at 10:48 PM, Rakib Mullick rakib.mull...@gmail.com wrote: On Sat, Mar 9, 2013 at 2:33 PM, Eric W. Biederman ebied...@xmission.com wrote: Rakib Mullick rakib.mull...@gmail.com writes: On Fri, Mar 8, 2013 at 10:01 PM, Eric W. Biederman ebied...@xmission.com wrote: When

Re: [nsproxy] BUG: unable to handle kernel NULL pointer dereference at 0000000000000024

On Sat, Mar 9, 2013 at 2:33 PM, Eric W. Biederman wrote: > Rakib Mullick writes: > >> On Fri, Mar 8, 2013 at 10:01 PM, Eric W. Biederman >> wrote: >>> >>> When a new task is created one of two things needs to happen. >>> A) A reference count needs

Re: [nsproxy] BUG: unable to handle kernel NULL pointer dereference at 0000000000000024

On Sat, Mar 9, 2013 at 2:33 PM, Eric W. Biederman ebied...@xmission.com wrote: Rakib Mullick rakib.mull...@gmail.com writes: On Fri, Mar 8, 2013 at 10:01 PM, Eric W. Biederman ebied...@xmission.com wrote: When a new task is created one of two things needs to happen. A) A reference count

Re: [nsproxy] BUG: unable to handle kernel NULL pointer dereference at 0000000000000024

On Fri, Mar 8, 2013 at 10:01 PM, Eric W. Biederman wrote: > > When a new task is created one of two things needs to happen. > A) A reference count needs to be added to the current nsproxy. > B) B a new nsproxy needs to be created. > > The way that code works today is far from a shiny example of

Re: [nsproxy] BUG: unable to handle kernel NULL pointer dereference at 0000000000000024

On 3/7/13, Eric W. Biederman wrote: > Fengguang Wu writes: > >> Greetings, >> >> I got the below oops and the first bad commit is > > Doh! On a second look that change is totally wrong. Of course we need > to up the ref-count every time we create a new process. Especially if > we don't do

Re: [nsproxy] BUG: unable to handle kernel NULL pointer dereference at 0000000000000024

On 3/7/13, Eric W. Biederman ebied...@xmission.com wrote: Fengguang Wu fengguang...@intel.com writes: Greetings, I got the below oops and the first bad commit is Doh! On a second look that change is totally wrong. Of course we need to up the ref-count every time we create a new process.

Re: [nsproxy] BUG: unable to handle kernel NULL pointer dereference at 0000000000000024

On Fri, Mar 8, 2013 at 10:01 PM, Eric W. Biederman ebied...@xmission.com wrote: When a new task is created one of two things needs to happen. A) A reference count needs to be added to the current nsproxy. B) B a new nsproxy needs to be created. The way that code works today is far from a

[PATCH] nsproxy: Fix ->nsproxy counting problem in copy_namespace.

>From cd41495e25cf2641ffe9e01a40d3d221a46b08be Mon Sep 17 00:00:00 2001 From: Rakib Mullick Date: Thu, 7 Mar 2013 14:52:20 +0600 Subject: [PATCH] nsproxy: Fix ->nsproxy counting problem in copy_namespace. In copy_namespace(), get_nsproxy() (which increments nsproxy->count) is calle

[PATCH] nsproxy: Fix -nsproxy counting problem in copy_namespace.

From cd41495e25cf2641ffe9e01a40d3d221a46b08be Mon Sep 17 00:00:00 2001 From: Rakib Mullick rakib.mull...@gmail.com Date: Thu, 7 Mar 2013 14:52:20 +0600 Subject: [PATCH] nsproxy: Fix -nsproxy counting problem in copy_namespace. In copy_namespace(), get_nsproxy() (which increments nsproxy-count

Re: [RFC] sched: The removal of idle_balance()

On Mon, Feb 18, 2013 at 9:25 PM, Steven Rostedt wrote: > On Mon, 2013-02-18 at 13:43 +0530, Srikar Dronamraju wrote: >> > The cache misses dropped by ~23% and migrations dropped by ~28%. I >> > really believe that the idle_balance() hurts performance, and not just >> > for something like

Re: [RFC] sched: The removal of idle_balance()

On Mon, Feb 18, 2013 at 9:25 PM, Steven Rostedt rost...@goodmis.org wrote: On Mon, 2013-02-18 at 13:43 +0530, Srikar Dronamraju wrote: The cache misses dropped by ~23% and migrations dropped by ~28%. I really believe that the idle_balance() hurts performance, and not just for something like

Re: [RFC] sched: nohz_idle_balance

On 9/13/12, Peter Zijlstra wrote: > On Thu, 2012-09-13 at 08:49 +0200, Mike Galbraith wrote: >> On Thu, 2012-09-13 at 06:11 +0200, Vincent Guittot wrote: > > Well, updating the load statistics on the cpu you're going to balance > seems like a good end to me.. ;-) No point updating the local

  1   2   >