Re: [PATCH 9/9] mmc: Convert from tasklet to BH workqueue

Hello, On Thu, Mar 28, 2024 at 01:53:25PM +0100, Ulf Hansson wrote: > At this point we have suggested to drivers to switch to use threaded > irq handlers (and regular work queues if needed too). That said, > what's the benefit of using the BH work queue? BH workqueues should behave about the

Re: [Bisected] [commit dd6c3c544126] [linux-next] [6.8.0-rc2] Task hungs for infinite time call traces

Hello, On Mon, Feb 05, 2024 at 03:24:17PM +0530, Tasmiya Nalatwad wrote: > Greetings, > > [Linux-next] [6.8.0-rc2-next-20240130] [FC / XFS] Task hangs for infinite > time while running bonnie test XFS filesystem > > Bisected the issue. Git bisect points to the below commit > commit

Re: linux-next: boot warning

On Tue, May 09, 2023 at 05:09:43PM +1000, Michael Ellerman wrote: > Stephen Rothwell writes: > > Hi all, > > > > Today's qemu test boot (powerpc pseries_le_defconfig) produced this > > warning: > > > > [2.048588][T1] ipr: IBM Power RAID SCSI Device Driver version: > > 2.6.4 (March 14,

Re: [PATCH 01/22] powerpc, workqueue: Use alloc_ordered_workqueue() to create ordered workqueues

Applied to wq/for-6.5-cleanup-ordered. Thanks. -- tejun

[PATCH 01/22] powerpc, workqueue: Use alloc_ordered_workqueue() to create ordered workqueues

ays reconsider later. As there are follow-up workqueue core changes, I'd really appreciate if the patch can be routed through the workqueue tree w/ your acks. Thanks. Signed-off-by: Tejun Heo Cc: Michael Ellerman Cc: Nicholas Piggin Cc: Christophe Leroy Cc: Nathan Lynch Cc: linuxppc-

Re: [PATCH 1/3] powerpc/cacheinfo: Use cpumap_print to print cpumap

On Mon, Jun 29, 2020 at 04:07:01PM +0530, Srikar Dronamraju wrote: > Tejun Heo had modified shared_cpu_map_show to use scnprintf instead of > cpumap_print during support for *pb[l] format. > Refer commit 0c118b7bd09a ("powerpc: use %*pb[l] to print bitmaps including > cpuma

Re: [PATCH 1/2] powerpc/workqueue: update list of possible CPUs

Hello, Laurent. On Thu, Aug 24, 2017 at 02:10:31PM +0200, Laurent Vivier wrote: > > Yeah, it just needs to match up new cpus to the cpu ids assigned to > > the right node. > > We are not able to assign the cpu ids to the right node before the CPU > is present, because firmware doesn't provide

Re: [PATCH 1/2] powerpc/workqueue: update list of possible CPUs

Hello, Michael. On Wed, Aug 23, 2017 at 09:00:39PM +1000, Michael Ellerman wrote: > > I don't think that's true. The CPU id used in kernel doesn't have to > > match the physical one and arch code should be able to pre-map CPU IDs > > to nodes and use the matching one when hotplugging CPUs. I'm

Re: [PATCH 1/2] powerpc/workqueue: update list of possible CPUs

Hello, Michael. On Tue, Aug 22, 2017 at 11:41:41AM +1000, Michael Ellerman wrote: > > This is something powerpc needs to fix. > > There is no way for us to fix it. I don't think that's true. The CPU id used in kernel doesn't have to match the physical one and arch code should be able to

Re: [PATCH 2/2] blk-mq: don't use WORK_CPU_UNBOUND

On Mon, Aug 21, 2017 at 03:49:51PM +0200, Laurent Vivier wrote: > cpumask is the list of CPUs present when the queue is built. > If a new CPU is hotplugged, this list is not updated, > and when the scheduler asks for a CPU id, blk_mq_hctx_next_cpu() > can return WORK_CPU_UNBOUND. > And in this

Re: [PATCH 1/2] powerpc/workqueue: update list of possible CPUs

On Mon, Aug 21, 2017 at 03:49:50PM +0200, Laurent Vivier wrote: > In wq_numa_init() a list of NUMA nodes with their list of possible CPUs > is built. > > Unfortunately, on powerpc, the Firmware is only able to provide the > node of a CPU if the CPU is present. So, in our case (possible CPU) > CPU

[PATCH cgroup/for-4.13-fixes] cgroup: don't call migration methods if there are no tasks to migrate

>From 610467270fb368584b74567edd21c8cc5104490f Mon Sep 17 00:00:00 2001 From: Tejun Heo <t...@kernel.org> Date: Sat, 8 Jul 2017 07:17:02 -0400 Subsystem migration methods shouldn't be called for empty migrations. cgroup_migrate_execute() implements this guarantee by bail

Re: [next-20170609] Oops while running CPU off-on (cpuset.c/cpuset_can_attach)

Hello, Abdul. Thanks for the debug info. Can you please see whether the following patch fixes the issue? If the problem is too difficult to reproduce to confirm the fix by seeing whether it no longer triggers, please let me know. We can instead apply a patch which triggers WARN on the failing

Re: kworker with empty task->cpus_allowed (was Re: [v4.12-rc1 regression] mount ext4 fs results in kernel crash on PPC64le host)

Hello, Michael. On Fri, Jun 30, 2017 at 11:08:22AM +1000, Michael Ellerman wrote: > Tejun Heo <t...@kernel.org> writes: > > > Could be the same problem as the one reported in the following thread. > > > > http://lkml.kernel.org/r/1497266622.15415.39.ca...@abdul.in.

Re: kworker with empty task->cpus_allowed (was Re: [v4.12-rc1 regression] mount ext4 fs results in kernel crash on PPC64le host)

Hello, Could be the same problem as the one reported in the following thread. http://lkml.kernel.org/r/1497266622.15415.39.ca...@abdul.in.ibm.com The root cause there is ppc arch code not setting up possible cpu <-> numa mapping during boot. Thanks. -- tejun

Re: [next-20170609] Oops while running CPU off-on (cpuset.c/cpuset_can_attach)

Hello, Abdul. Sorry about the long delay. On Mon, Jun 12, 2017 at 04:53:42PM +0530, Abdul Haleem wrote: > linux-next kernel crashed while running CPU offline and online. > > Machine: Power 8 LPAR > Kernel : 4.12.0-rc4-next-20170609 > gcc : version 5.2.1 > config: attached > testcase: CPU off/on

Re: [next-20170609] WARNING: CPU: 3 PID: 71167 at lib/idr.c:157 idr_replace

On Thu, Jun 22, 2017 at 12:31:35AM +0100, Chris Wilson wrote: > Quoting Tejun Heo (2017-06-13 14:58:49) > > Cc'ing David Airlie. > > > > This is from drm driver calling in idr_replace() w/ a negative id. > > Probably a silly bug in error handling path? >

Re: WARNING: CPU: 2 PID: 7 at kernel/workqueue.c:2041 process_one_work

On Tue, May 30, 2017 at 01:24:06PM +0530, Abdul Haleem wrote: > Hi, > > Test : stress-ng > Machine : Power 8 Bare Metal > Kernel : 4.12.0-rc3 > Config : attached > gcc version: 4.8.5 > > > In file kernel/workqueue.c at line 2041 > > /* ensure we're on the correct CPU */ >

Re: [next-20170609] WARNING: CPU: 3 PID: 71167 at lib/idr.c:157 idr_replace

Cc'ing David Airlie. This is from drm driver calling in idr_replace() w/ a negative id. Probably a silly bug in error handling path? Thanks. On Mon, Jun 12, 2017 at 08:10:54PM +0530, Abdul Haleem wrote: > Hi, > > WARN_ON_ONCE is being called from idr_replace() function in file > lib/idr.c at

Re: [PATCH v2] workqueue: Fix edge cases for calc of pool's cpumask

Hello, On Tue, Jun 06, 2017 at 09:34:05AM -0500, Michael Bringmann wrote: > >> diff --git a/kernel/workqueue.c b/kernel/workqueue.c > >> index c74bf39..460de61 100644 > >> --- a/kernel/workqueue.c > >> +++ b/kernel/workqueue.c > >> @@ -3366,6 +3366,9 @@ static struct worker_pool

Re: [PATCH v2] workqueue: Fix edge cases for calc of pool's cpumask

these and other cases, the patch attempts to ensure that a valid, > usable cpumask is used to set up newly created pools for workqueues. > > Signed-off-by: Tejun Heo <t...@kernel.org> & Michael Bringmann > <m...@linux.vnet.ibm.com> Heh, you can't add sob's f

Re: [PATCH] kernfs: Check KERNFS_HAS_RELEASE before calling kernfs_release_file()

Hello, Greg. On Tue, Mar 14, 2017 at 11:08:29AM +0800, Greg Kroah-Hartman wrote: > Tejun, want to take this through your tree, or at the least, give me an > ack for this? Just acked. I think going through your tree is better for this one. Thanks! -- tejun

Re: [PATCH] kernfs: Check KERNFS_HAS_RELEASE before calling kernfs_release_file()

t_handler+0x1e8/0x1f0 > [c00f1680bdc0] [c00d384c] kthread+0x14c/0x190 > [c00f1680be30] [c000b5a0] ret_from_kernel_thread+0x5c/0xbc > > Fixes: f83f3c515654("kernfs: fix locking around kernfs_ops->release() > callback") > Signed-off-by: Vaibhav Jain <vaib...@linux.vnet.ibm.com> Acked-by: Tejun Heo <t...@kernel.org> Thanks. -- tejun

Re: [mm v2 0/3] Support memory cgroup hotplug

Hello, Balbir. On Tue, Nov 29, 2016 at 11:09:26AM +1100, Balbir Singh wrote: > On 29/11/16 08:10, Tejun Heo wrote: > > On Thu, Nov 24, 2016 at 12:05:12AM +1100, Balbir Singh wrote: > >> On my desktop NODES_SHIFT is 6, many distro kernels have it a 9. I've known > >>

Re: [mm v2 0/3] Support memory cgroup hotplug

On Thu, Nov 24, 2016 at 12:05:12AM +1100, Balbir Singh wrote: > On my desktop NODES_SHIFT is 6, many distro kernels have it a 9. I've known > of solutions that use fake NUMA for partitioning and need as many nodes as > possible. It was a crude kludge that people used before memcg. If people

Re: [v1 0/3] Support memory cgroup hotplug

ch > adds hotplug support to memory cgroups and reverts the commit that > limited possible nodes to online nodes. > > Cc: Tejun Heo <t...@kernel.org> > Cc: Andrew Morton <a...@linux-foundation.org> Can you please cc memcg maintainers? Johannes Weiner <han...@cmpxch

[PATCH wq/for-4.10] workqueue: move wq_numa_init() to workqueue_init()

Hello, Michael. I simplified the patch a bit and applied the following to for-4.10 and updated for-next accordingly. The coming next snapshot should be fine. Thanks! -- 8< -- >From 2186d9f940b6a04f263a3bacd48f2a7ba96df4cf Mon Sep 17 00:00:00 2001 From: Tejun Heo <t...@kernel.

Re: Oops on Power8 (was Re: [PATCH v2 1/7] workqueue: make workqueue available early during boot)

Hello, Michael. On Tue, Oct 18, 2016 at 03:37:42PM +1100, Michael Ellerman wrote: > That doesn't compile, wq doesn't exist. > > I guessed that you meant: > > + wq_numa_init(); > + list_for_each_entry(wq, , list) > + wq_update_unbound_numa(wq, smp_processor_id(), true);

Re: Oops on Power8 (was Re: [PATCH v2 1/7] workqueue: make workqueue available early during boot)

Hello, Michael. Other NUMA archs are lazy-initializing cpu to node mapping too, so we need to fix it from workqueue side. This also means that we've been getting NUMA node wrong for percpu pools on those archs. Can you please try the following patch and if it resolves the issue, report the

Re: Oops on Power8 (was Re: [PATCH v2 1/7] workqueue: make workqueue available early during boot)

Hello, Michael. On Mon, Oct 17, 2016 at 11:24:34PM +1100, Michael Ellerman wrote: > The bad case (where we hit the BUG_ON I added above) is where we are > creating a wq for node 1. > > In wq_calc_node_cpumask() we do: > > cpumask_and(cpumask, attrs->cpumask,

Re: Oops on Power8 (was Re: [PATCH v2 1/7] workqueue: make workqueue available early during boot)

Hello, On Sat, Oct 15, 2016 at 08:48:01PM +1100, Michael Ellerman wrote: > > Hmm... it doesn't reproduce it here and can't see how the commit would > > affect this given that it doesn't really change when the kworker > > kthreads are being created. > > Try turning on CONFIG_DEBUG_PER_CPU_MAPS=y

Re: Oops on Power8 (was Re: [PATCH v2 1/7] workqueue: make workqueue available early during boot)

Hello, Balbir. On Tue, Oct 11, 2016 at 11:21:09PM +1100, Balbir Singh wrote: > FYI: I see the samething on my cpu as well, its just that I get lucky > and cpu_online(cpu) returns false. Are you seeing this on x86 or is your test setup also a power machine? Thanks. -- tejun

Re: Oops on Power8 (was Re: [PATCH v2 1/7] workqueue: make workqueue available early during boot)

Hello, Michael. On Tue, Oct 11, 2016 at 10:22:13PM +1100, Michael Ellerman wrote: > The oops happens because we're in enqueue_task_fair() and p->se->cfs_rq > is NULL. > > The cfs_rq is NULL because we did set_task_rq(p, 2048), where 2048 is > NR_CPUS. That causes us to index past the end of the

Re: Oops on Power8 (was Re: [PATCH v2 1/7] workqueue: make workqueue available early during boot)

On Mon, Oct 10, 2016 at 09:02:53AM -0400, Tejun Heo wrote: > Hello, Michael. > > On Mon, Oct 10, 2016 at 09:22:55PM +1100, Michael Ellerman wrote: > > This patch seems to be causing one of my Power8 boxes not to boot. > > > > Specifically commit 3347fa092821 ("wor

Re: Oops on Power8 (was Re: [PATCH v2 1/7] workqueue: make workqueue available early during boot)

Hello, Michael. On Mon, Oct 10, 2016 at 09:22:55PM +1100, Michael Ellerman wrote: > This patch seems to be causing one of my Power8 boxes not to boot. > > Specifically commit 3347fa092821 ("workqueue: make workqueue available > early during boot") in linux-next. > > If I revert this on top of

Re: Oops on Power8 (was Re: [PATCH v2 1/7] workqueue: make workqueue available early during boot)

On Mon, Oct 10, 2016 at 10:17:16PM +1100, Balbir Singh wrote: > rest_init() > { > ... > kernel_thread(kernel_init, NULL, CLONE_FS); > numa_default_policy(); > pid = kernel_thread(kthreadd, NULL, CLONE_FS | CLONE_FILES); > rcu_read_lock(); > kthreadd_task =

Re: [PATCH] percpu: improve generic percpu modify-return implementation

Hello, On Thu, Sep 22, 2016 at 02:35:00PM +1000, Nicholas Piggin wrote: > Well thank you, how about you? Heh, can't complain. Hope to see you around sometime. It's been forever. > Trying a new mail client, sorry. It *seems* to be working now, how's > this? Hmm... Still encoded. > From

Re: [PATCH] percpu: improve generic percpu modify-return implementation

Hello, Nick. How have you been? :) On Wed, Sep 21, 2016 at 08:57:11PM +1000, Nicholas Piggin wrote: > On Wed, 21 Sep 2016 18:51:37 +1000 > Nicholas Piggin wrote: > > > Some architectures require an additional load to find the address of > > percpu pointers. In some

Re: [PATCH] ps3: Remove deprecated create_singlethread_workqueue

e > increase of local concurrency shouldn't make any difference. > > The work item has been flushed in ps3av_remove to ensure that > there are no pending tasks while disconnecting the driver. > > Signed-off-by: Bhaktipriya Shridhar <bhaktipriy...@gmail.com> Acked-by: Tejun Heo <t...@kernel.org> Thanks. -- tejun

Re: [PATCH 2/2] workqueue:Fix affinity of an unbound worker of a node with 1 online CPU

On Fri, Jul 15, 2016 at 03:30:41PM +1000, Michael Ellerman wrote: > It looks like this still hasn't gone to Linus for 4.7? > > Could it please, it's a pretty nasty regression on our boxes. Sorry about that. Just sent out the pull request. Thanks. -- tejun

Re: [PATCH 1/2] workqueue: Move wq_update_unbound_numa() to the beginning of CPU_ONLINE

On Tue, Jun 21, 2016 at 09:37:09PM +0200, Peter Zijlstra wrote: > Hurm.. So I've applied it, just to get this issue sorted, but I'm not > entirely sure I like it. > > I think I prefer ego's version because that makes it harder to get stuff > to run on !active,online cpus. I think we really want

Re: [PATCH 1/2] workqueue: Move wq_update_unbound_numa() to the beginning of CPU_ONLINE

t; CPU_ONLINE callbacks should be able to put kthreads on the CPU which > > is coming online. Update select_fallback_rq() so that it follows > > cpu_online() rather than cpu_active() for kthreads. > > > > Signed-off-by: Tejun Heo <t...@kernel.org> > > Reported-by:

Re: [PATCH 2/2] workqueue:Fix affinity of an unbound worker of a node with 1 online CPU

On Thu, Jun 16, 2016 at 02:45:48PM +0200, Peter Zijlstra wrote: > Subject: workqueue: Fix setting affinity of unbound worker threads > From: Peter Zijlstra > Date: Thu Jun 16 14:38:42 CEST 2016 > > With commit e9d867a67fd03ccc ("sched: Allow per-cpu kernel threads to > run

Re: [PATCH 1/2] workqueue: Move wq_update_unbound_numa() to the beginning of CPU_ONLINE

rather than cpu_active() for kthreads. Signed-off-by: Tejun Heo <t...@kernel.org> Reported-by: Gautham R Shenoy <e...@linux.vnet.ibm.com> --- kernel/sched/core.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index

Re: [PATCH 2/2] workqueue:Fix affinity of an unbound worker of a node with 1 online CPU

Hello, On Wed, Jun 15, 2016 at 03:14:15PM +0200, Peter Zijlstra wrote: > On Wed, Jun 15, 2016 at 06:20:33PM +0530, Gautham R Shenoy wrote: > > We will no longer have the optimization in > > restore_unbound_workers_cpumask() but I suppose we don't lose much by > > resetting the affinity every time

Re: [PATCH 1/2] workqueue: Move wq_update_unbound_numa() to the beginning of CPU_ONLINE

Hello, On Tue, Jun 07, 2016 at 08:44:02PM +0530, Gautham R. Shenoy wrote: > Currently in the CPU_ONLINE workqueue handler, the > restore_unbound_workers_cpumask() will never call > set_cpus_allowed_ptr() for a newly created unbound worker thread. Hmmm... did you actually verify that this

Re: [PATCH v2 00/23] ata: sata_dwc_460ex: make it working again

Hello, On Tue, May 10, 2016 at 11:34:40AM +0530, Vinod Koul wrote: > > slave-dma [1], branch topic/dw. But I think Vinod can tell us which > > tag/branch will be immutable. Vinod? > > Please use branch topic/dw. I will not rebase this before sending to Linus. Okay, pulled topic/dw into

Re: [PATCH v2 00/23] ata: sata_dwc_460ex: make it working again

On Mon, May 09, 2016 at 10:13:59AM +0100, Måns Rullgård wrote: > Andy Shevchenko <andy.shevche...@gmail.com> writes: > > > On Mon, May 9, 2016 at 4:09 AM, Tejun Heo <t...@kernel.org> wrote: > >> On Sun, May 08, 2016 at 04:00:08PM -0400, Tejun Heo wrote: > >

Re: [PATCH v2 00/23] ata: sata_dwc_460ex: make it working again

On Sun, May 08, 2016 at 04:00:08PM -0400, Tejun Heo wrote: > Hello, Andy. > > On Wed, May 04, 2016 at 03:22:51PM +0300, Andy Shevchenko wrote: > > Tejun, since Vinod applied all necessary patches into his tree, the > > series now has just a dependency to whatever

Re: [PATCH v2 00/23] ata: sata_dwc_460ex: make it working again

Hello, Andy. On Wed, May 04, 2016 at 03:22:51PM +0300, Andy Shevchenko wrote: > Tejun, since Vinod applied all necessary patches into his tree, the > series now has just a dependency to whatever branch / tag he marks for > it. > Do we have a chance to see the SATA series be applied in your tree?

Re: [PATCH v2 03/23] ata: sata_dwc_460ex: set dma_boundary to 0x1fff

On Tue, Apr 26, 2016 at 12:03:04PM +0300, Andy Shevchenko wrote: > diff --git a/drivers/ata/sata_dwc_460ex.c b/drivers/ata/sata_dwc_460ex.c > index 7f95389..aee8873 100644 > --- a/drivers/ata/sata_dwc_460ex.c > +++ b/drivers/ata/sata_dwc_460ex.c > @@ -1151,7 +1151,13 @@ static struct

Re: [RFC PATCH 1/2] powerpc/numa: fix cpu_to_node() usage during boot

Hello, On Wed, Jul 15, 2015 at 03:43:51PM -0700, Nishanth Aravamudan wrote: Ok, thank you for clarifying! From a correctness perspective, even if the numbers don't match NUMA nodes, should we expect the grouping to be split along NUMA topology? Yeap, the groups get formed according to the

Re: [RFC,1/2] powerpc/numa: fix cpu_to_node() usage during boot

Hello, On Fri, Jul 10, 2015 at 09:15:47AM -0700, Nishanth Aravamudan wrote: On 08.07.2015 [16:16:23 -0700], Nishanth Aravamudan wrote: On 08.07.2015 [14:00:56 +1000], Michael Ellerman wrote: On Thu, 2015-02-07 at 23:02:02 UTC, Nishanth Aravamudan wrote: Much like on x86, now that

Re: [RFC PATCH 1/2] powerpc/numa: fix cpu_to_node() usage during boot

Hello, On Thu, Jul 02, 2015 at 04:02:02PM -0700, Nishanth Aravamudan wrote: we currently emit at boot: [0.00] pcpu-alloc: [0] 0 1 2 3 [0] 4 5 6 7 After this commit, we correctly emit: [0.00] pcpu-alloc: [0] 0 1 2 3 [1] 4 5 6 7 JFYI, the numbers in the brackets aren't

Re: [PATCH 1/1] ata: select DW_DMAC in case of SATA_DWC

On Tue, May 05, 2015 at 12:14:03PM +0300, Andy Shevchenko wrote: Since sata_dwc_460ex.c was moved to generic DMA driver we have to ensure that user can still compile it. Fixes: 8b3444852a2b (sata_dwc_460ex: move to generic DMA driver) Signed-off-by: Andy Shevchenko

Re: Kernel 4.1-rc1 build fails on Sam460ex amcc 460ex powerpc Canyonlands

On Mon, May 04, 2015 at 08:18:30PM +0300, Andy Shevchenko wrote: On Mon, 2015-04-27 at 23:49 -0400, Tejun Heo wrote: On Tue, Apr 28, 2015 at 11:12:25AM +1000, Michael Ellerman wrote: On Mon, 2015-04-27 at 06:59 -0400, Julian Margetson wrote: Kernel 4.1-rc1 build fails on Sam460ex amcc

Re: Kernel 4.1-rc1 build fails on Sam460ex amcc 460ex powerpc Canyonlands

On Tue, Apr 28, 2015 at 11:12:25AM +1000, Michael Ellerman wrote: On Mon, 2015-04-27 at 06:59 -0400, Julian Margetson wrote: Kernel 4.1-rc1 build fails on Sam460ex amcc 460ex powerpc Canyonlands with CONFIG_SATA_DWC=y sata_dwc_460ex.c:(.text+0xa165c): undefined reference to

Re: [PATCH v2 2/3] Remove celleb-only SCC PATA drivers

On Tue, Apr 14, 2015 at 01:58:14PM +0200, Bartlomiej Zolnierkiewicz wrote: If Tejun Dave are OK with it this patch can go through libata tree. Otherwise you will need to split it on separate libata/IDE patches. I really don't care which tree this goes through. Dave, if you wanna take it,

Re: [PATCH v1 2/2] sata_dwc_460ex: re-use hsdev-dev instead of dwc_dev

On Tue, Mar 03, 2015 at 10:41:22PM +0200, Andy Shevchenko wrote: This patch re-uses hsdev-dev which is allocated on heap. Therefore, the private structure, which is global variable, is reduced by one field. In one case ap-dev is used and there it seems to be right decision. Signed-off-by:

Re: [RFC PATCH] powerpc/numa: reset node_possible_map to only node_online_map

On Thu, Mar 05, 2015 at 10:05:49AM -0800, Nishanth Aravamudan wrote: While looking at this, I noticed that nr_node_ids is actually a misnomer, it seems. It's not the number, but the maximum_node_id, as with sparse NUMA nodes, you might only have two NUMA nodes possible, but to make certain

Re: [RFC PATCH] powerpc/numa: reset node_possible_map to only node_online_map

On Thu, Mar 05, 2015 at 03:21:35PM -0800, Nishanth Aravamudan wrote: So, do you agree with the general direction of my change? :) Yeah, I mean it's an obvious bug fix. I don't know when or how it should be set on powerpc but if the machine can't do NUMA node hotplug, its node online and

Re: [RFC PATCH] powerpc/numa: reset node_possible_map to only node_online_map

On Thu, Mar 05, 2015 at 05:08:04PM -0500, Tejun Heo wrote: It can be argued that we should always stick to the online masks for allocation and iteration; however, that usually requires more complexity and the only cases where this mattered have been when the boot code got it wrong and failed

Re: [RFC PATCH] powerpc/numa: reset node_possible_map to only node_online_map

Hello, On Thu, Mar 05, 2015 at 01:58:27PM -0800, David Rientjes wrote: I'm not sure why this is being proposed as a powerpc patch and now a patch for mem_cgroup_css_alloc(). In other words, why do we have to allocate for all possible nodes? We should only be allocating for online nodes in

Re: [PATCH] sata-fsl: Apply link speed limits

On Thu, Feb 19, 2015 at 03:05:47PM -0500, Martin Hicks wrote: The driver was ignoring limits requested by libata.force. The output would look like: fsl-sata ffe18000.sata: Sata FSL Platform/CSB Driver init ata1: FORCE: PHY spd limit set to 1.5Gbps ata1: SATA max UDMA/133 irq 74 ata1:

Re: [PATCH 02/15] sata_svw: remove the dependency on PPC_OF

-by: Kevin Hao haoke...@gmail.com Acked-by: Tejun Heo t...@kernel.org Please route as you see fit. Thanks. -- tejun ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH 2/3] topology: support node_numa_mem() for determining the fallback node

Hello, On Tue, Jul 22, 2014 at 02:43:11PM -0700, Nishanth Aravamudan wrote: ... There is an issue currently where NUMA information is used on powerpc (and possibly ia64) before it has been read from the device-tree, which leads to large slab consumption with CONFIG_SLUB and

Re: [RFC 0/2] Memoryless nodes and kworker

On Thu, Jul 17, 2014 at 04:09:23PM -0700, Nishanth Aravamudan wrote: [Apologies for the large Cc list, but I believe we have the following interested parties: x86 (recently posted memoryless node support) ia64 (existing memoryless node support) ppc (existing memoryless node support)

Re: [RFC 0/2] Memoryless nodes and kworker

Hello, On Fri, Jul 18, 2014 at 10:42:29AM -0700, Nish Aravamudan wrote: So, to be clear, this is not *necessarily* about memoryless nodes. It's about the semantics intended. The workqueue code currently calls cpu_to_node() in a few places, and passes that node into the core MM as a hint about

Re: [RFC 0/2] Memoryless nodes and kworker

On Fri, Jul 18, 2014 at 02:00:08PM -0400, Tejun Heo wrote: This isn't a huge issue but it shows that this is the wrong layer to deal with this issue. Let the allocators express where they are. ^ allocator users Choosing

Re: [RFC 0/2] Memoryless nodes and kworker

Hello, On Fri, Jul 18, 2014 at 11:12:01AM -0700, Nish Aravamudan wrote: why aren't these callers using kthread_create_on_cpu()? That API was It is using that. There just are other data structures too. already change to use cpu_to_mem() [so one change, rather than of all over the kernel

Re: [RFC 0/2] Memoryless nodes and kworker

Hello, On Fri, Jul 18, 2014 at 11:47:08AM -0700, Nish Aravamudan wrote: Why are any callers of the format kthread_create_on_node(..., cpu_to_node(cpu), ...) not using kthread_create_on_cpu(..., cpu, ...)? Ah, okay, that's because unbound workers are NUMA node affine, not CPU. It seems like

Re: Node 0 not necessary for powerpc?

On Tue, Jun 10, 2014 at 04:31:57PM -0700, Nishanth Aravamudan wrote: I think what this really wants to do is NODE_DATA(cpu_to_mem(cpu)) and I thought ppc had the cpu-to-local-memory-node mappings correct? Except cpu_to_mem relies on the mapping being defined, but early in boot,

Re: Node 0 not necessary for powerpc?

Hello, On Wed, May 21, 2014 at 09:16:27AM -0500, Christoph Lameter wrote: On Mon, 19 May 2014, Nishanth Aravamudan wrote: I'm seeing a panic at boot with this change on an LPAR which actually has no Node 0. Here's what I think is happening: start_kernel ... -

[PATCH 2/9] ps3-vuart: don't use PREPARE_WORK

-off-by: Tejun Heo t...@kernel.org Cc: Geoff Levand ge...@infradead.org Cc: linuxppc-dev@lists.ozlabs.org Cc: cbe-oss-...@lists.ozlabs.org --- drivers/ps3/ps3-vuart.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/ps3/ps3-vuart.c b/drivers/ps3/ps3-vuart.c index fb73008

Re: [PATCH 1/8] IBM Akebono: Add support to AHCI platform driver

Hello, On Thu, Nov 21, 2013 at 9:08 PM, Alistair Popple alist...@popple.id.au wrote: The new IBM Akebono board has a PPC476GTR SoC with an AHCI compliant SATA controller. This patch adds a compatible property for the new SoC to the AHCI platform driver. Signed-off-by: Alistair Popple

Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern

Hello, On Tue, Oct 08, 2013 at 02:22:16PM +0200, Alexander Gordeev wrote: If we talk about pSeries quota, then the current pSeries pci_enable_msix() implementation is racy internally and could fail if the quota went down *while* pci_enable_msix() is executing. In this case the loop will have

Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern

Hello, On Wed, Oct 09, 2013 at 02:57:16PM +0200, Alexander Gordeev wrote: On Mon, Oct 07, 2013 at 02:01:11PM -0400, Tejun Heo wrote: Hmmm... yean, the race condition could be an issue as multiple msi allocation might fail even if the driver can and explicitly handle multiple allocation

Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern

On Mon, Oct 07, 2013 at 09:48:01PM +0100, Ben Hutchings wrote: There is one major flaw in min-max approach - the generic MSI layer will have to take decisions on exact number of MSIs to request, not device drivers. [... No, the min-max functions should be implemented using the same loop

Re: [PATCH RFC 07/77] PCI/MSI: Re-design MSI/MSI-X interrupts enablement pattern

Hello, Alexander. On Tue, Oct 08, 2013 at 09:48:26AM +0200, Alexander Gordeev wrote: If there are many which duplicate the above pattern, it'd probably be worthwhile to provide a helper? It's usually a good idea to reduce the amount of boilerplate code in drivers. I wanted to limit

Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern

Hello, On Tue, Oct 08, 2013 at 11:07:16AM +0200, Alexander Gordeev wrote: Multipe MSIs is just a handful of drivers, really. MSI-X impact still Yes, so it's pretty nice to try out things there before going full-on. will be huge. But if we opt a different name for the new pci_enable_msix()

Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern

Hey, guys. On Sun, Oct 06, 2013 at 09:10:30AM +0200, Alexander Gordeev wrote: On Sun, Oct 06, 2013 at 05:19:46PM +1100, Benjamin Herrenschmidt wrote: On Sun, 2013-10-06 at 08:02 +0200, Alexander Gordeev wrote: In fact, in the current design to address the quota race decently the drivers

Re: [PATCH RFC 05/77] PCI/MSI: Convert pci_msix_table_size() to a public interface

Hello, On Wed, Oct 02, 2013 at 12:48:21PM +0200, Alexander Gordeev wrote: Make pci_msix_table_size() to return a error code if the device does not support MSI-X. This update is needed to facilitate a forthcoming re-design MSI/MSI-X interrupts enabling pattern. Device drivers will use this

Re: [PATCH RFC 07/77] PCI/MSI: Re-design MSI/MSI-X interrupts enablement pattern

Hello, On Wed, Oct 02, 2013 at 12:48:23PM +0200, Alexander Gordeev wrote: +static int foo_driver_enable_msi(struct foo_adapter *adapter, int nvec) +{ + rc = pci_get_msi_cap(adapter-pdev); + if (rc 0) + return rc; + + nvec = min(nvec, rc); + if (nvec

Re: [PATCH RFC 00/77] Re-design MSI/MSI-X interrupts enablement pattern

Hello, Alexander. On Wed, Oct 02, 2013 at 12:48:16PM +0200, Alexander Gordeev wrote: Alexander Gordeev (77): PCI/MSI: Fix return value when populate_msi_sysfs() failed PCI/MSI/PPC: Fix wrong RTAS error code reporting PCI/MSI/s390: Fix single MSI only check PCI/MSI/s390: Remove

Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface

Hello, On Tue, Oct 01, 2013 at 05:35:48PM +1000, Michael Ellerman wrote: Roughly third of the drivers just do not care and bail out once pci_enable_msix() has not succeeded. Not sure how many of these are mandated by the hardware. Yeah, I mean, this type of interface is a trap.

Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface

On Wed, Oct 02, 2013 at 12:33:38PM +1000, Michael Ellerman wrote: It is an interface which forces the driver writers to write complicated fallback code which won't usually be excercised. It does not force anyone to do anything. That's just bull. Yeah, sure, we don't have shitty code in

Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface

Hello, On Thu, Sep 26, 2013 at 09:46:46AM +0200, Alexander Gordeev wrote: Can you please go into a bit of detail on that? Why does it matter? Because otherwise we will re-introduce a problem described by Michael: We have a small number of MSIs available, limited by hardware firmware, if

Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface

Hello, On Thu, Sep 26, 2013 at 10:39 AM, Alexander Gordeev agord...@redhat.com wrote: I can imagine a scenario where the first device probes in, requests its Well, we can imagine a lot of thing but usually have to draw the line somewhere. optimal number, acquires that number and exhausts MSIs

Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface

Hello, On Wed, Sep 25, 2013 at 10:58:05PM +0200, Alexander Gordeev wrote: Unfortunately, pSeries is a shows-topper here :( It seems we have to introduce pci_get_msi{,x}_limit() interfaces to honour the quota thing. I just hope the hardware set for pSeries is limited and we won't need to use

Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()

direct write accesses to using the correct API. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Acked-by: Tejun Heo t...@kernel.org The patch is pretty widely spread. I don't mind how it gets routed but what's the plan? Thanks. -- tejun

Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()

On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote: On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote: The correct way for a driver to specify the coherent DMA mask is not to directly access the field in the struct device, but to use dma_set_coherent_mask(). Only arch

Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface

Hello, On Wed, Sep 18, 2013 at 06:50:45PM +0200, Alexander Gordeev wrote: Actually, I do not see much contradiction with what I proposed. The key words here determine the number of MSIs the controller wants. In general case it is not what pci_msix_table_size() returns (or at least we should

Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface

On Fri, Sep 20, 2013 at 10:24:59AM +0200, Alexander Gordeev wrote: * Make pci_enable_msix() return 0/-errno My choice would be this one. Thanks. -- tejun ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org

Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()

Hey, On Fri, Sep 20, 2013 at 03:00:18PM +0100, Russell King - ARM Linux wrote: Another would be if subsystem maintainers are happy that I carry them, I can add the acks, and then later on towards the end of the cycle, provide a branch subsystem maintainers could pull. Or... if you can think

Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface

Hello, On Wed, Sep 18, 2013 at 11:48:00AM +0200, Alexander Gordeev wrote: On Wed, Sep 18, 2013 at 12:30:23AM +1000, Michael Ellerman wrote: How about no? We have a small number of MSIs available, limited by hardware firmware, if we don't impose a quota then the first device that probes

Re: [PATCH] sata: fsl: save irqs while coalescing

On Mon, Aug 19, 2013 at 07:20:30PM -0600, Anthony Foiani wrote: This patch is based off linux-next tag next-20130819 (which is commit 66a01bae29d11916c09f9f5a937cafe7d402e4a5 ) Signed-off-by: Anthony Foiani anthony.foi...@gmail.com Applied to libata/for-3.11-fixes w/ stable cc'd. Thanks.

Re: [PATCH v2 15/45] rcu: Use get/put_online_cpus_atomic() to prevent CPU offline

On Wed, Jun 26, 2013 at 10:51:11AM -0400, Steven Rostedt wrote: It would also increase the latency of CPU-hotunplug operations. Is that a big deal? I thought that was the whole deal with this patchset - making cpu hotunplugs lighter and faster mostly for powersaving. That said, just

Re: [PATCH v2 15/45] rcu: Use get/put_online_cpus_atomic() to prevent CPU offline

Hello, On Wed, Jun 26, 2013 at 11:33:43AM -0400, Steven Rostedt wrote: I thought the whole deal with this patchset was to remove stop_machine from CPU hotplug. Why halt all CPUs just to remove one? stomp_machine() is extremely intrusive for the entire system, where as one CPU making sure all

Re: [PATCH v2 15/45] rcu: Use get/put_online_cpus_atomic() to prevent CPU offline

Hey, On Wed, Jun 26, 2013 at 11:58:48PM +0530, Srivatsa S. Bhat wrote: Yes, we were discussing hot-unplug latency for use-cases such as suspend/resume. We didn't want to make those operations slower in the process of removing stop_machine() from hotplug. Can you please explain why tho? How

Re: [PATCH 22/45] percpu_counter: Use get/put_online_cpus_atomic() to prevent CPU offline

On Sun, Jun 23, 2013 at 07:12:59PM +0530, Srivatsa S. Bhat wrote: Once stop_machine() is gone from the CPU offline path, we won't be able to depend on disabling preemption to prevent CPUs from going offline from under us. Use the get/put_online_cpus_atomic() APIs to prevent CPUs from going

  1   2   >